From dholmes at openjdk.org  Mon Sep  1 05:13:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 05:13:45 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v4]
In-Reply-To: <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>
 <xvfT4UTH12qNL2XdpS1HpUxbesJu2HkxOq-btMgL8ao=.bfa7e1a7-09b7-4f24-b49b-f038812e2ae7@github.com>
 <aOC-wve-ARp11g2AId1AFZMlybtobEFl-s0s1MuPtP8=.6850a2c1-e870-4acb-8c18-2f28514e9cbb@github.com>
 <ej_YqB2uft5_dHdSAt8VTxBQoSpW9MXtfj1lZ9pb0MI=.171572f8-c4e6-42c9-99b4-e8340d83b33c@github.com>
 <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com>
Message-ID: <qV4AaZCC2kLHlaIaGxqLJWL1COEHSXierm_80cUchAA=.4c072686-2481-4a2d-9540-fee79488e4db@github.com>

On Fri, 29 Aug 2025 06:54:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> But we are only in this method because the Java method has completed normally so there cannot be a pending exception at this point. ???
>
> There is might be exception if current method has been called after exception has been thrown. It is quite rare case, but I've seem when add `assert(!exception_exit, "")`. It might happens if exception thrown  and there were other upcals  in the same thread before exception has been caught. I think I've seen it during classloading or some method bootstrapping.
> 
> The test `TestMethodExitWithPendingException`  simulates the same issue by calling method in the MethodExit event call back.
> For method `upCall` the `exception_exit` would be true, because the method is called while exception is pending. However, the method `upCall` exits normally and is not unwinded. So this method `post_method_exit` is called.
> 
> Here is the example of such stack in the on of the tests were assertion has been hit. The VM tries to load classes when exception is throwing.
> 
> V  [libjvm.so+0x1415d6c]  JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x29c  (jvmtiExport.cpp:1847)
> V  [libjvm.so+0x1066b86]  InterpreterRuntime::post_method_exit(JavaThread*)+0xe6  (interpreterRuntime.cpp:1278)
> j  java.lang.Object.<init>()V+0 java.base at 26-internal
> j  java.lang.Throwable.<init>(Ljava/lang/String;)V+1 java.base at 26-internal
> j  java.lang.Error.<init>(Ljava/lang/String;)V+2 java.base at 26-internal
> j  java.lang.LinkageError.<init>(Ljava/lang/String;)V+2 java.base at 26-internal
> j  java.lang.NoClassDefFoundError.<init>(Ljava/lang/String;)V+2 java.base at 26-internal
> v  ~StubRoutines::Stub Generator call_stub_stub 0x00007f81b7c876fd
> V  [libjvm.so+0x1089117]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4f7  (javaCalls.cpp:415)
> V  [libjvm.so+0x108ab3f]  JavaCalls::call_special(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x18f  (javaCalls.cpp:323)
> V  [libjvm.so+0x108b3c6]  JavaCalls::construct_new_instance(InstanceKlass*, Symbol*, JavaCallArguments*, JavaThread*)+0x116  (javaCalls.cpp:289)
> V  [libjvm.so+0xd74f4b]  Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle)+0x1db  (exceptions.cpp:320)
> V  [libjvm.so+0xd7517f]  Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle, Handle)+0x2f  (exceptions.cpp:341)
> V  [libjvm.so+0xd7609f]  Exceptions::new_exception(JavaThread*, Symbol*, char const*, Handle, Handle, Exceptions::ExceptionMsgToUtf8Mode)+0x3bf  (exceptions.cpp:424)
> V  [libjvm.so+0xd7b9a0]  Exceptions::_throw_msg_cause(JavaThread*, char const*, int, Symbol*, char co...

Sorry I still can't see this. Method A throws an exception. The callback for the method-exit event for method A then invokes Java method B. Method B also has a callback enabled and so we are processing the method-exit for B. Method B has completed normally, but the exception from method A is still listed as pending? I can't see how that would come about as we must (temporarily) clear the pending exception to do the upcall else the upcall method would immediately throw that pending exception. But if we have cleared it then the upcall method's method-exit event shouldn't be able to see it. Similarly we must save/restore the JvmtiThreadState else we would be processing the normal exit as if it were an exception one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2312899717

From dholmes at openjdk.org  Mon Sep  1 05:22:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 05:22:53 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v4]
In-Reply-To: <qV4AaZCC2kLHlaIaGxqLJWL1COEHSXierm_80cUchAA=.4c072686-2481-4a2d-9540-fee79488e4db@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>
 <xvfT4UTH12qNL2XdpS1HpUxbesJu2HkxOq-btMgL8ao=.bfa7e1a7-09b7-4f24-b49b-f038812e2ae7@github.com>
 <aOC-wve-ARp11g2AId1AFZMlybtobEFl-s0s1MuPtP8=.6850a2c1-e870-4acb-8c18-2f28514e9cbb@github.com>
 <ej_YqB2uft5_dHdSAt8VTxBQoSpW9MXtfj1lZ9pb0MI=.171572f8-c4e6-42c9-99b4-e8340d83b33c@github.com>
 <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com>
 <qV4AaZCC2kLHlaIaGxqLJWL1COEHSXierm_80cUchAA=.4c072686-2481-4a2d-9540-fee79488e4db@github.com>
Message-ID: <1n0gbxAE37Nf7SHwUFLwCr1fJ2W4EuPh88kxMyO8un0=.5e803b50-f08f-4887-8d4c-3eb37156a754@github.com>

On Mon, 1 Sep 2025 05:11:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There is might be exception if current method has been called after exception has been thrown. It is quite rare case, but I've seem when add `assert(!exception_exit, "")`. It might happens if exception thrown  and there were other upcals  in the same thread before exception has been caught. I think I've seen it during classloading or some method bootstrapping.
>> 
>> The test `TestMethodExitWithPendingException`  simulates the same issue by calling method in the MethodExit event call back.
>> For method `upCall` the `exception_exit` would be true, because the method is called while exception is pending. However, the method `upCall` exits normally and is not unwinded. So this method `post_method_exit` is called.
>> 
>> Here is the example of such stack in the on of the tests were assertion has been hit. The VM tries to load classes when exception is throwing.
>> 
>> V  [libjvm.so+0x1415d6c]  JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x29c  (jvmtiExport.cpp:1847)
>> V  [libjvm.so+0x1066b86]  InterpreterRuntime::post_method_exit(JavaThread*)+0xe6  (interpreterRuntime.cpp:1278)
>> j  java.lang.Object.<init>()V+0 java.base at 26-internal
>> j  java.lang.Throwable.<init>(Ljava/lang/String;)V+1 java.base at 26-internal
>> j  java.lang.Error.<init>(Ljava/lang/String;)V+2 java.base at 26-internal
>> j  java.lang.LinkageError.<init>(Ljava/lang/String;)V+2 java.base at 26-internal
>> j  java.lang.NoClassDefFoundError.<init>(Ljava/lang/String;)V+2 java.base at 26-internal
>> v  ~StubRoutines::Stub Generator call_stub_stub 0x00007f81b7c876fd
>> V  [libjvm.so+0x1089117]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4f7  (javaCalls.cpp:415)
>> V  [libjvm.so+0x108ab3f]  JavaCalls::call_special(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x18f  (javaCalls.cpp:323)
>> V  [libjvm.so+0x108b3c6]  JavaCalls::construct_new_instance(InstanceKlass*, Symbol*, JavaCallArguments*, JavaThread*)+0x116  (javaCalls.cpp:289)
>> V  [libjvm.so+0xd74f4b]  Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle)+0x1db  (exceptions.cpp:320)
>> V  [libjvm.so+0xd7517f]  Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle, Handle)+0x2f  (exceptions.cpp:341)
>> V  [libjvm.so+0xd7609f]  Exceptions::new_exception(JavaThread*, Symbol*, char const*, Handle, Handle, Exceptions::ExceptionMsgToUtf8Mode)+0x3bf  (exceptions.cpp:424)
>> V  [libjvm.so+0xd7b9a0]  Exceptions::_throw_msg_cause(Jav...
>
> Sorry I still can't see this. Method A throws an exception. The callback for the method-exit event for method A then invokes Java method B. Method B also has a callback enabled and so we are processing the method-exit for B. Method B has completed normally, but the exception from method A is still listed as pending? I can't see how that would come about as we must (temporarily) clear the pending exception to do the upcall else the upcall method would immediately throw that pending exception. But if we have cleared it then the upcall method's method-exit event shouldn't be able to see it. Similarly we must save/restore the JvmtiThreadState else we would be processing the normal exit as if it were an exception one.

Or mabye I do get it. The actual pending exception (on the ThreadShadow) must be saved, cleared and later restored, else we can't execute the Java upcall. But because we have separate paths for normal and exceptional method-exit processing, maybe we don't have to save/restore the JvmtiThreadState exception fields? But in that case are those fields even useful? To be honest I can't see how the two fields interact: there is either no exception being thrown, or there is - so only one field needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2312908009

From duke at openjdk.org  Mon Sep  1 06:30:50 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 1 Sep 2025 06:30:50 GMT
Subject: Integrated: 8366331: Sort share/prims includes
In-Reply-To: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
Message-ID: <n7LAIGaUntkxuZAzDnutowLEIHYLxQJK4PQYo7lHMNI=.ad15947a-58ad-4e85-aef2-8cc1f3571ded@github.com>

On Thu, 28 Aug 2025 09:04:04 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`.
> 
> Passes `tier1`.

This pull request has now been integrated.

Changeset: 12dc568b
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12dc568b3d270e4ab6dcd07e1bcddbb024ad724a
Stats:     71 lines in 26 files changed: 30 ins; 39 del; 2 mod

8366331: Sort share/prims includes

Reviewed-by: shade, lmesnik

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

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

From mbaesken at openjdk.org  Mon Sep  1 06:51:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 06:51:51 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v3]
In-Reply-To: <mFCocD24ZlodX8iS45JnH_8H2-RLYBTPOFTu-OyCTYU=.c7641333-d14c-44f8-bb68-4c796c619dc8@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
 <mFCocD24ZlodX8iS45JnH_8H2-RLYBTPOFTu-OyCTYU=.c7641333-d14c-44f8-bb68-4c796c619dc8@github.com>
Message-ID: <bEKfrPhjDuaHSIsY8fOE7RQQnQzH23u2zsg6AoMg2F8=.d9115c81-049e-464a-809d-37795a304522@github.com>

On Fri, 29 Aug 2025 14:11:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When using gcc static analyzer (-fanalyzer) with gcc 13.2 the following issue is reported :
>> 
>> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c: In function 'get_jvmticks':
>> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c:208:24: warning: use of uninitialized value 'systemTicks' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
>>   208 | pticks->usedKernel = systemTicks;
>> 
>> 
>> vsscanf usually/normally reads the systemTicks info from /proc file system. see
>> https://github.com/openjdk/jdk/blob/45726a1f8b8f76586037867a32b82f8ab9b96937/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L163
>> but we never check that the *exact* number of params is read with vsscanf :
>> n = vsscanf(tmp, fmt, args);
>> So potentially we could get a non complete info without systemTicks and the call would still succeed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid initialization

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26962#issuecomment-3241061930

From mbaesken at openjdk.org  Mon Sep  1 06:51:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 06:51:52 GMT
Subject: Integrated: 8366092: [GCC static analyzer] UnixOperatingSystem.c
 warning: use of uninitialized value 'systemTicks'
In-Reply-To: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
Message-ID: <TTMF7LYIf07e9_Id2jwixL1OfifmOKMTabWU-00HUos=.9c4337f2-d222-489b-9a75-cdd758eb701c@github.com>

On Wed, 27 Aug 2025 14:23:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using gcc static analyzer (-fanalyzer) with gcc 13.2 the following issue is reported :
> 
> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c: In function 'get_jvmticks':
> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c:208:24: warning: use of uninitialized value 'systemTicks' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
>   208 | pticks->usedKernel = systemTicks;
> 
> 
> vsscanf usually/normally reads the systemTicks info from /proc file system. see
> https://github.com/openjdk/jdk/blob/45726a1f8b8f76586037867a32b82f8ab9b96937/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L163
> but we never check that the *exact* number of params is read with vsscanf :
> n = vsscanf(tmp, fmt, args);
> So potentially we could get a non complete info without systemTicks and the call would still succeed.

This pull request has now been integrated.

Changeset: a6e2a329
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6e2a329a07c71582ac696809fb5349c6a0b681c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8366092: [GCC static analyzer] UnixOperatingSystem.c warning: use of uninitialized value 'systemTicks'

Reviewed-by: kevinw, asteiner

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

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

From dholmes at openjdk.org  Mon Sep  1 07:00:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 07:00:45 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v2]
In-Reply-To: <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
 <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
Message-ID: <LNOhyyZoOqDheYd5ykb1ioYtW7Auwv7-AJ4PXtoZbJU=.85171d55-bb4c-4999-af15-f708fec3269c@github.com>

On Sat, 30 Aug 2025 17:34:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
>> 
>> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
>> - tests if an object is inside the AOT cache's metaspace region.
>> 
>> Also various forms of  "shared metaspace" are updated to "aot metaspace"
>> 
>> Please start your review with allocations.hpp
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017

Maybe the JBS title should be a bit more generic as you seem to be renaming many occurrences of "shared" not just the one listed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27016#issuecomment-3241088446

From lkorinth at openjdk.org  Mon Sep  1 08:07:48 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 1 Sep 2025 08:07:48 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth 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 10 additional commits since the last revision:

 - new timeouts
 - Merge branch '_master_jdk' into _8260555
 - update copyright
 - revert added timeout, it is not needed
 - feedback from Mark Sheppard
 - update testing.md, remove makefile link, fix bad text
 - after suggestion from Daniel
 - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD
 - After suggestions from Erik and Andrey
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8

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

  Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

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

From kevinw at openjdk.org  Mon Sep  1 08:34:46 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 1 Sep 2025 08:34:46 GMT
Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v3]
In-Reply-To: <Wl7oJEfbnsO3_W8nBWMBgf6FQO6oaOXQbekmaAY4XWY=.d6a7b6fa-d042-41e4-b713-f87791a7be4d@github.com>
References: <ZItLUA6qC4OkLvIijLnEFv9OpBDuuR4iOvudXerRcVo=.9e48a280-8247-4d35-973e-446fa6a7e668@github.com>
 <Wl7oJEfbnsO3_W8nBWMBgf6FQO6oaOXQbekmaAY4XWY=.d6a7b6fa-d042-41e4-b713-f87791a7be4d@github.com>
Message-ID: <dB4hNXOYYWw6lhSkyleCZ7tHcAHUoYd90e8skp56d9U=.56a0842d-64c9-40ee-831a-53216075d805@github.com>

On Wed, 30 Jul 2025 17:54:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE.  We should recognise a null object and return the wrapped exception we document.
>> 
>> This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException.
>> 
>> Docs:
>> https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName)
>> 
>> Throws:
>> RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified.
>> 
>> 
>> Current behaviour:
>> 
>> 
>> $ java MBS_NPE.java
>> Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null
>>         at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296)
>>         at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511)
>>         at MBS_NPE.main(MBS_NPE.java:11)
>> 
>> 
>> Should be changed to:
>> 
>> 
>> $ java MBS_NPE.java
>> javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean
>>         at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297)
>>         at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511)
>>         at MBS_NPE.main(MBS_NPE.java:11)
>>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258)
>>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
>> Caused by: java.lang.IllegalArgumentException: Object cannot be null
>>         at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295)
>>         ... 7 more
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One more case

Adding release note before integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/26548#issuecomment-3241400647

From kevinw at openjdk.org  Mon Sep  1 08:56:07 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 1 Sep 2025 08:56:07 GMT
Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v4]
In-Reply-To: <ZItLUA6qC4OkLvIijLnEFv9OpBDuuR4iOvudXerRcVo=.9e48a280-8247-4d35-973e-446fa6a7e668@github.com>
References: <ZItLUA6qC4OkLvIijLnEFv9OpBDuuR4iOvudXerRcVo=.9e48a280-8247-4d35-973e-446fa6a7e668@github.com>
Message-ID: <1v3Z9KtyiSDQ8hzy2DBBUS9rI-UZiASYWXDt6-VTWbI=.644e0068-7a22-4a25-b82c-e1c03b57dad9@github.com>

> A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE.  We should recognise a null object and return the wrapped exception we document.
> 
> This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException.
> 
> Docs:
> https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName)
> 
> Throws:
> RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified.
> 
> 
> Current behaviour:
> 
> 
> $ java MBS_NPE.java
> Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null
>         at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296)
>         at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511)
>         at MBS_NPE.main(MBS_NPE.java:11)
> 
> 
> Should be changed to:
> 
> 
> $ java MBS_NPE.java
> javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean
>         at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297)
>         at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511)
>         at MBS_NPE.main(MBS_NPE.java:11)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
> Caused by: java.lang.IllegalArgumentException: Object cannot be null
>         at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295)
>         ... 7 more

Kevin Walls 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 'upstream/master' into 8364227_MBS_NPE
 - One more case
 - comment update
 - Add test for exceptions thrown in response to null params.
 - 8364227: MBeanServer registerMBean throws NPE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26548/files
  - new: https://git.openjdk.org/jdk/pull/26548/files/671c6eaa..a1d7f82a

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

  Stats: 59841 lines in 1607 files changed: 38007 ins; 15471 del; 6363 mod
  Patch: https://git.openjdk.org/jdk/pull/26548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26548/head:pull/26548

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

From lkorinth at openjdk.org  Mon Sep  1 13:21:49 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 1 Sep 2025 13:21:49 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <TiRHp5dX-u2OuPlu50hedoCquJu_ULL3srzudIySQtM=.f58f3b1f-8b8e-48a0-bde4-058578cbbc13@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19

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

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

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

From alanb at openjdk.org  Mon Sep  1 13:55:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Sep 2025 13:55:46 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9]
In-Reply-To: <TiRHp5dX-u2OuPlu50hedoCquJu_ULL3srzudIySQtM=.f58f3b1f-8b8e-48a0-bde4-058578cbbc13@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <TiRHp5dX-u2OuPlu50hedoCquJu_ULL3srzudIySQtM=.f58f3b1f-8b8e-48a0-bde4-058578cbbc13@github.com>
Message-ID: <ujm7_UShZE9eDdqhqg82kiSLMXpbiTi3jzOahQcKKZk=.3c13c859-73ec-4e94-9980-6c49dd414c72@github.com>

On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701

From kevinw at openjdk.org  Mon Sep  1 14:24:58 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 1 Sep 2025 14:24:58 GMT
Subject: Integrated: 8364227: MBeanServer registerMBean throws NPE
In-Reply-To: <ZItLUA6qC4OkLvIijLnEFv9OpBDuuR4iOvudXerRcVo=.9e48a280-8247-4d35-973e-446fa6a7e668@github.com>
References: <ZItLUA6qC4OkLvIijLnEFv9OpBDuuR4iOvudXerRcVo=.9e48a280-8247-4d35-973e-446fa6a7e668@github.com>
Message-ID: <LC4rLuwVrdzEiIhdeJC_CbCSps15T9pAFkT9RkruuT4=.6ce54f0a-65a9-445c-a8ab-fc997d1ac646@github.com>

On Wed, 30 Jul 2025 11:19:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE.  We should recognise a null object and return the wrapped exception we document.
> 
> This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException.
> 
> Docs:
> https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName)
> 
> Throws:
> RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified.
> 
> 
> Current behaviour:
> 
> 
> $ java MBS_NPE.java
> Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null
>         at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296)
>         at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511)
>         at MBS_NPE.main(MBS_NPE.java:11)
> 
> 
> Should be changed to:
> 
> 
> $ java MBS_NPE.java
> javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean
>         at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297)
>         at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511)
>         at MBS_NPE.main(MBS_NPE.java:11)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
> Caused by: java.lang.IllegalArgumentException: Object cannot be null
>         at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295)
>         ... 7 more

This pull request has now been integrated.

Changeset: b06459d3
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b06459d3a83c13c0fbc7a0a7698435f17265982e
Stats:     204 lines in 2 files changed: 201 ins; 0 del; 3 mod

8364227: MBeanServer registerMBean throws NPE

Reviewed-by: alanb

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

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

From lkorinth at openjdk.org  Mon Sep  1 16:00:47 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 1 Sep 2025 16:00:47 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com>

On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31:
> 
>> 29:  * @compile SuspendResume2.java
>> 30:  * @run driver jdk.test.lib.FileInstaller . .
>> 31:  * @run main/othervm/native/timeout=700
> 
> Why `700` instead of `480` in this file?

I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387

From lkorinth at openjdk.org  Mon Sep  1 16:09:44 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 1 Sep 2025 16:09:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <plR6IBqt_CP-kbXrzVRQ-ZHQcmVAxFFHDkeXOA-fM5M=.0facc4e4-3564-42d5-978e-8173723f8d07@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
 <plR6IBqt_CP-kbXrzVRQ-ZHQcmVAxFFHDkeXOA-fM5M=.0facc4e4-3564-42d5-978e-8173723f8d07@github.com>
Message-ID: <XStMsQl326UKR-4OlFju2IInzF6OMuVVMc-mfZ70kh8=.a886c6e5-b103-4b52-aeae-5a8c756c8d89@github.com>

On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4).
>
>> while not multiplying a 10x factor with four resulting in a 40x factor.
> 
> Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000)  * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO.

Because 40x is a very large timeout factor. I think I might misunderstand you in some way.

My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263

From lmesnik at openjdk.org  Tue Sep  2 01:16:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Sep 2025 01:16:55 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v4]
In-Reply-To: <1n0gbxAE37Nf7SHwUFLwCr1fJ2W4EuPh88kxMyO8un0=.5e803b50-f08f-4887-8d4c-3eb37156a754@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>
 <xvfT4UTH12qNL2XdpS1HpUxbesJu2HkxOq-btMgL8ao=.bfa7e1a7-09b7-4f24-b49b-f038812e2ae7@github.com>
 <aOC-wve-ARp11g2AId1AFZMlybtobEFl-s0s1MuPtP8=.6850a2c1-e870-4acb-8c18-2f28514e9cbb@github.com>
 <ej_YqB2uft5_dHdSAt8VTxBQoSpW9MXtfj1lZ9pb0MI=.171572f8-c4e6-42c9-99b4-e8340d83b33c@github.com>
 <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com>
 <qV4AaZCC2kLHlaIaGxqLJWL1COEHSXierm_80cUchAA=.4c072686-2481-4a2d-9540-fee79488e4db@github.com>
 <1n0gbxAE37Nf7SHwUFLwCr1fJ2W4EuPh88kxMyO8un0=.5e803b50-f08f-4887-8d4c-3eb37156a754@github.com>
Message-ID: <tV2pVhkRkGqj5UTa5sJpuGTgg-lmH-pJQzTp5x1DiZI=.387e3536-47c5-46c7-ad7a-5435a7b9a86a@github.com>

On Mon, 1 Sep 2025 05:19:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sorry I still can't see this. Method A throws an exception. The callback for the method-exit event for method A then invokes Java method B. Method B also has a callback enabled and so we are processing the method-exit for B. Method B has completed normally, but the exception from method A is still listed as pending? I can't see how that would come about as we must (temporarily) clear the pending exception to do the upcall else the upcall method would immediately throw that pending exception. But if we have cleared it then the upcall method's method-exit event shouldn't be able to see it. Similarly we must save/restore the JvmtiThreadState else we would be processing the normal exit as if it were an exception one.
>
> Or mabye I do get it. The actual pending exception (on the ThreadShadow) must be saved, cleared and later restored, else we can't execute the Java upcall. But because we have separate paths for normal and exceptional method-exit processing, maybe we don't have to save/restore the JvmtiThreadState exception fields? But in that case are those fields even useful? To be honest I can't see how the two fields interact: there is either no exception being thrown, or there is - so only one field needed.

BTW, I forget to mention that the 
`state->is_exception_detected() && !state->is_exception_caught();`
is just the same as  
`state->is_exception_detected()`
Because exception state is enum an if it is `ES_DETECTED` then it can't be `ES_CAUGHT`. 

Am I understand correctly, that you propose to clear/restore `_exception_state` for any upcall since it is the separate execution path?  In this case it should be done in every place where java is called from vm while exception is in detected state. It makes sense to keep this field consistent.

I looked on the `_exception_state` in the `JvmtiThreadState` and is also used in the `notice_unwind_due_to_exception`. But it is unclear how it can be false in this method. 
Also, it is used in the `post_exception_throw` and it also unclear what is checked there. And seems it is not used in any other places.

So, probably, this state is not useful if method exit/exception posting work without it. Or it is needed to find all places where it is should be saved/restored. It might includes methodExit events but there are other places that should be fixed.  It is needed to change this line to assertion and see where it is hit. 
However, I think it could be done separately. It is too complicated for this fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2314718031

From iklam at openjdk.org  Tue Sep  2 01:38:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Sep 2025 01:38:16 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass*
Message-ID: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>

By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code


InstanceKlass* ik;
InstanceKlass* s;
s = InstanceKlass::cast(ik->super()); // before JDK-8366024 
s = ik->java_super(); // after JDK-8366024 


to


s = k->super();


So you no longer need to do casting or need to understand what `java_super()` is.

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

Commit messages:
 - 8366584: Add an InstanceKlass::super() method that returns InstanceKlass*

Changes: https://git.openjdk.org/jdk/pull/27037/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27037&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366584
  Stats: 91 lines in 28 files changed: 8 ins; 2 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/27037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27037/head:pull/27037

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

From dholmes at openjdk.org  Tue Sep  2 03:57:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Sep 2025 03:57:53 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v4]
In-Reply-To: <tV2pVhkRkGqj5UTa5sJpuGTgg-lmH-pJQzTp5x1DiZI=.387e3536-47c5-46c7-ad7a-5435a7b9a86a@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>
 <xvfT4UTH12qNL2XdpS1HpUxbesJu2HkxOq-btMgL8ao=.bfa7e1a7-09b7-4f24-b49b-f038812e2ae7@github.com>
 <aOC-wve-ARp11g2AId1AFZMlybtobEFl-s0s1MuPtP8=.6850a2c1-e870-4acb-8c18-2f28514e9cbb@github.com>
 <ej_YqB2uft5_dHdSAt8VTxBQoSpW9MXtfj1lZ9pb0MI=.171572f8-c4e6-42c9-99b4-e8340d83b33c@github.com>
 <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com>
 <qV4AaZCC2kLHlaIaGxqLJWL1COEHSXierm_80cUchAA=.4c072686-2481-4a2d-9540-fee79488e4db@github.com>
 <1n0gbxAE37Nf7SHwUFLwCr1fJ2W4EuPh88kxMyO8un0=.5e803b50-f08f-4887-8d4c-3eb37156a754@github.com>
 <tV2pVhkRkGqj5UTa5sJpuGTgg-lmH-pJQzTp5x1DiZI=.387e3536-47c5-46c7-ad7a-5435a7b9a86a@github.com>
Message-ID: <3XY_bM2M8_J57W_owMK6TRa2bQWELfIpVd4KvCPGvcI=.348b3b15-6b59-41f6-a8ea-051eb8a5a0c0@github.com>

On Tue, 2 Sep 2025 01:13:40 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Or mabye I do get it. The actual pending exception (on the ThreadShadow) must be saved, cleared and later restored, else we can't execute the Java upcall. But because we have separate paths for normal and exceptional method-exit processing, maybe we don't have to save/restore the JvmtiThreadState exception fields? But in that case are those fields even useful? To be honest I can't see how the two fields interact: there is either no exception being thrown, or there is - so only one field needed.
>
> BTW, I forget to mention that the 
> `state->is_exception_detected() && !state->is_exception_caught();`
> is just the same as  
> `state->is_exception_detected()`
> Because exception state is enum an if it is `ES_DETECTED` then it can't be `ES_CAUGHT`. 
> 
> Am I understand correctly, that you propose to clear/restore `_exception_state` for any upcall since it is the separate execution path?  In this case it should be done in every place where java is called from vm while exception is in detected state. It makes sense to keep this field consistent.
> 
> I looked on the `_exception_state` in the `JvmtiThreadState` and is also used in the `notice_unwind_due_to_exception`. But it is unclear how it can be false in this method. 
> Also, it is used in the `post_exception_throw` and it also unclear what is checked there. And seems it is not used in any other places.
> 
> So, probably, this state is not useful if method exit/exception posting work without it. Or it is needed to find all places where it is should be saved/restored. It might includes methodExit events but there are other places that should be fixed.  It is needed to change this line to assertion and see where it is hit. 
> However, I think it could be done separately. It is too complicated for this fix.

I think this state, and its use, needs more examination, but yes that can be deferred to another issue. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2314852578

From dholmes at openjdk.org  Tue Sep  2 05:39:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Sep 2025 05:39:49 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass*
In-Reply-To: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
Message-ID: <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>

On Tue, 2 Sep 2025 01:31:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code
> 
> 
> InstanceKlass* ik;
> InstanceKlass* s;
> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 
> s = ik->java_super(); // after JDK-8366024 
> 
> 
> to
> 
> 
> s = k->super();
> 
> 
> So you no longer need to do casting or need to understand what `java_super()` is.

Looks good! Great to see all those `java_super()` calls disappear. A couple of nits/comments.

Thanks

src/hotspot/share/memory/heapInspection.cpp line 405:

> 403:                                                       bool print_subclasses) {
> 404:   // Set do_print for all superclasses of this class.
> 405:   InstanceKlass* super = InstanceKlass::cast(cie->klass())->super();

Pre-existing, but if this cast is safe then `KlassInfoEntry::_klass` should be declared `InstanceKlass`. Otherwise this cast is not safe! Separate RFE for that.

src/hotspot/share/oops/instanceKlass.hpp line 921:

> 919:   }
> 920: 
> 921:   // This shadows Klass::super(). The _super of an InstanceKlass is

Suggestion:

  // This overrides Klass::super(). The _super of an InstanceKlass is

src/hotspot/share/oops/instanceKlass.hpp line 924:

> 922:   // always an InstanceKlass (or nullptr)
> 923:   InstanceKlass* super() const {
> 924:     return (Klass::super() == nullptr) ? nullptr : InstanceKlass::cast(Klass::super());

Is it better/simpler/cleaner to just do:

return static_cast<InstanceKlass*>(Klass::super());

?

src/hotspot/share/oops/klassVtable.cpp line 1574:

> 1572:   Klass* super = _klass->super();
> 1573:   if (super != nullptr) {
> 1574:     InstanceKlass* sk = InstanceKlass::cast(super); // why are we sure this is InstanceKlass??

I don't think it is guaranteed to be an IK. But AFAICS we don't actually need an IK here anyway, we should be able to use `super` directly.

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

PR Review: https://git.openjdk.org/jdk/pull/27037#pullrequestreview-3174870461
PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2314910364
PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2314913536
PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2314912896
PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2314951109

From dholmes at openjdk.org  Tue Sep  2 07:10:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Sep 2025 07:10:43 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass*
In-Reply-To: <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
Message-ID: <-jsZbxQ5S-quQBlUaeX5L_uu9f1oZGprF3COQgXUlwg=.4e173397-8a0f-43c5-980c-4f78fee8e59c@github.com>

On Tue, 2 Sep 2025 04:59:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code
>> 
>> 
>> InstanceKlass* ik;
>> InstanceKlass* s;
>> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 
>> s = ik->java_super(); // after JDK-8366024 
>> 
>> 
>> to
>> 
>> 
>> s = k->super();
>> 
>> 
>> So you no longer need to do casting or need to understand what `java_super()` is.
>
> src/hotspot/share/oops/instanceKlass.hpp line 921:
> 
>> 919:   }
>> 920: 
>> 921:   // This shadows Klass::super(). The _super of an InstanceKlass is
> 
> Suggestion:
> 
>   // This overrides Klass::super(). The _super of an InstanceKlass is

Correction: this is not "overriding" as defined by C++. "shadow" is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2315125979

From lkorinth at openjdk.org  Tue Sep  2 07:29:57 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 2 Sep 2025 07:29:57 GMT
Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <P6nHDFNjBUkXCKl_HmrKnd59l9Tp4zojuLhIu6HJuMQ=.93c74f49-7b78-4f8e-b7fe-acf499ccc4f1@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

This pull request has now been integrated.

Changeset: 55e7af05
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1
Stats:     901 lines in 342 files changed: 51 ins; 91 del; 759 mod

8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Reviewed-by: alanb, sspitsyn, lmesnik, ihse

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

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

From jpai at openjdk.org  Tue Sep  2 09:36:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Sep 2025 09:36:46 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v4]
In-Reply-To: <ycjD7BT8p5lmyM44Tee59ugwvauK0t0E9z6bnzMsn88=.17ffe200-266e-4fbe-b726-86f96673d7c0@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <ycjD7BT8p5lmyM44Tee59ugwvauK0t0E9z6bnzMsn88=.17ffe200-266e-4fbe-b726-86f96673d7c0@github.com>
Message-ID: <qHbu9Qyu-nkqvt-8eJIKV3zZUHKiAz2EsDjKOiZAC-Y=.8faa16c4-b4f9-4e30-a79c-a826883a1fbd@github.com>

On Fri, 29 Aug 2025 22:48:06 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds linking a class before the `copy_bytecodes` method is called.
>> The PR also adds a regression test.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - The regression test passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich 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 branch 'master' into JDK-8277444
>  - Link classes before copy_bytecodes; Add regression test
>  - Symplify comments; Get JavaThread::current in variable
>  - Add missing include runtime/synchronizer.hpp
>  - 8277444: Race condition on Instrumentation.retransformClasses() and class linking

> The virtual thread test that is failing in this PR's GitHub actions job is `java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking#id0` 
> It looks like it's taking long to complete and that's causing the test timeout. I recollect that this test failure was addressed some time back, so this appears to be a new occurrence. In any case, this failure doesn't look related to the changes in this PR because I see some other PRs having failed with this same issue. I'll check and file an issue later today/tomorrow (unless anyone else gets to it first).

I've filed https://bugs.openjdk.org/browse/JDK-8366669 to track this failure.

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

PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3244555487

From fbredberg at openjdk.org  Tue Sep  2 11:07:00 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 2 Sep 2025 11:07:00 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
Message-ID: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>

Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).

This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.

Passes tier1-tier5 with no added problems.

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

Commit messages:
 - 8365190: Remove LockingMode related code from share

Changes: https://git.openjdk.org/jdk/pull/27041/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365190
  Stats: 1268 lines in 50 files changed: 6 ins; 1129 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/27041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041

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

From coleenp at openjdk.org  Tue Sep  2 11:49:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Sep 2025 11:49:44 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass*
In-Reply-To: <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
Message-ID: <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com>

On Tue, 2 Sep 2025 04:59:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code
>> 
>> 
>> InstanceKlass* ik;
>> InstanceKlass* s;
>> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 
>> s = ik->java_super(); // after JDK-8366024 
>> 
>> 
>> to
>> 
>> 
>> s = k->super();
>> 
>> 
>> So you no longer need to do casting or need to understand what `java_super()` is.
>
> src/hotspot/share/oops/instanceKlass.hpp line 924:
> 
>> 922:   // always an InstanceKlass (or nullptr)
>> 923:   InstanceKlass* super() const {
>> 924:     return (Klass::super() == nullptr) ? nullptr : InstanceKlass::cast(Klass::super());
> 
> Is it better/simpler/cleaner to just do:
> 
> return static_cast<InstanceKlass*>(Klass::super());
> 
> ?

I think the term is "hides" not "shadows".  InstanceKlass::cast() is better - one additional check that super is always another InstanceKlass.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2315826675

From coleenp at openjdk.org  Tue Sep  2 11:49:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Sep 2025 11:49:45 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass*
In-Reply-To: <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
 <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com>
Message-ID: <mpjy68MrkQtbiGPi5Nx6-NewHDGnRkgSYk_qqzjbG8A=.6759b5e5-3946-4477-b5d0-b0cd291070d9@github.com>

On Tue, 2 Sep 2025 11:43:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.hpp line 924:
>> 
>>> 922:   // always an InstanceKlass (or nullptr)
>>> 923:   InstanceKlass* super() const {
>>> 924:     return (Klass::super() == nullptr) ? nullptr : InstanceKlass::cast(Klass::super());
>> 
>> Is it better/simpler/cleaner to just do:
>> 
>> return static_cast<InstanceKlass*>(Klass::super());
>> 
>> ?
>
> I think the term is "hides" not "shadows".  InstanceKlass::cast() is better - one additional check that super is always another InstanceKlass.

Do we still need java_super ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2315827420

From coleenp at openjdk.org  Tue Sep  2 12:09:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Sep 2025 12:09:46 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v4]
In-Reply-To: <ycjD7BT8p5lmyM44Tee59ugwvauK0t0E9z6bnzMsn88=.17ffe200-266e-4fbe-b726-86f96673d7c0@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <ycjD7BT8p5lmyM44Tee59ugwvauK0t0E9z6bnzMsn88=.17ffe200-266e-4fbe-b726-86f96673d7c0@github.com>
Message-ID: <1JIJRz2n7-MCQDwQhqWAMC5o1VQ0gYwLZ1jgkjQH8YU=.c06407bf-e13b-4e35-84f9-ab2f4154f754@github.com>

On Fri, 29 Aug 2025 22:48:06 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds linking a class before the `copy_bytecodes` method is called.
>> The PR also adds a regression test.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - The regression test passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich 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 branch 'master' into JDK-8277444
>  - Link classes before copy_bytecodes; Add regression test
>  - Symplify comments; Get JavaThread::current in variable
>  - Add missing include runtime/synchronizer.hpp
>  - 8277444: Race condition on Instrumentation.retransformClasses() and class linking

I had a couple of minor comments but otherwise looks good.  Is the test now reliable?  Thank you for adding a test.

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 35:

> 33: #include "runtime/handles.inline.hpp"
> 34: #include "runtime/signature.hpp"
> 35: #include "runtime/synchronizer.hpp"

You don't need this include anymore.

src/hotspot/share/prims/jvmtiEnv.cpp line 3446:

> 3444:     current_thread->clear_pending_exception();
> 3445:     return JVMTI_ERROR_INVALID_CLASS;
> 3446:   }

Can you use the pattern:


    JavaThread* THREAD = current_thread;
    ... link_class(THREAD);
    if (HAS_PENDING_EXCEPTION)
      etc.

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

PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3176231981
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2315873660
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2315880585

From ayang at openjdk.org  Tue Sep  2 13:40:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 2 Sep 2025 13:40:41 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <U94hZ-F_Ttvx0apRTyrd9GMIdjDcrut6q5HM0iCeI2c=.bb3e750b-34da-4a64-b2b3-c2463e52a920@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3176613129

From rcastanedalo at openjdk.org  Tue Sep  2 13:48:45 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 2 Sep 2025 13:48:45 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <uTv7hGrRoKhLCxyY2SILmig-HZw0zE5Gh3wNLZ2R1LE=.0d6eb14f-b6aa-464e-9fac-87b829f32f84@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

src/hotspot/share/opto/phaseX.cpp line 1672:

> 1670:     // Found (linux x64 only?) with:
> 1671:     //   serviceability/sa/ClhsdbThreadContext.java
> 1672:     //   -XX:+UnlockExperimentalVMOptions -XX:LockingMode=1 -XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=1110

For traceability, I suggest leaving this line untouched and adding a comment in the next line clarifying that `-XX:LockingMode` is not available anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2316150051

From syan at openjdk.org  Tue Sep  2 15:16:13 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 2 Sep 2025 15:16:13 GMT
Subject: RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out
 after 60 second
Message-ID: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>

Hi all,

Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . After JDK-8260555 change the timeout factor from 4 to 1, so this timeout value should be ajusted.

Change has been verified locally, risk is low.

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

Commit messages:
 - 8366694: Test JdbStopInNotificationThreadTest.java timed out after 60 second

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

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

From cjplummer at openjdk.org  Tue Sep  2 18:18:46 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 2 Sep 2025 18:18:46 GMT
Subject: RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out
 after 60 second
In-Reply-To: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
References: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
Message-ID: <3fIKMR76GJ1JKPGZrmd4RXydp4pj92AcmYdvRjJtclc=.45344458-c4e8-4162-abbf-5bd19ccb9cd3@github.com>

On Tue, 2 Sep 2025 15:10:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . After JDK-8260555 change the timeout factor from 4 to 1, so this timeout value should be ajusted.
> 
> Change has been verified locally, risk is low.

test/jdk/com/sun/jdi/lib/jdb/Jdb.java line 80:

> 78:     private static final long sleepTime = 1000;
> 79:     // max time to wait for  jdb output (in ms)
> 80:     private static final long timeout = Utils.adjustTimeout(120000);

The way this is implemented is unfortunate. Jdb responses should normally be fairly quick. However, in this test the response doesn't happen until 10% of the java heap has been allocated, and I guess that can be slow sometimes. For some reason the test only allocates 8k at a time, and does a 100ms sleep every 1000 allocations. So now because of this one test, all tests need an unnecessary long timeout. I'm not sure of the reason for the sleep, but in general my suggestion would be to speed up how quickly the test gets to the point of 10% of the java heap being in use.  I think using a smaller heap would be the best choice here. Updating the main method to the following should work:


    public static void main(String argv[]) {
        JdbTest test = new JdbStopInNotificationThreadTest();
        test.launchOptions.addVMOptions("-Xmx64m")
        test.run();
    }


Possibly 64m is too small. Remember the trigger happens at 10% of that size, so will happen when 6.4m is allocated. Hopefully that isn't until after the debuggee is actually into the memory allocation code and not before. You may need to adjust higher.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27055#discussion_r2316825591

From dlong at openjdk.org  Tue Sep  2 19:27:37 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Sep 2025 19:27:37 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic
Message-ID: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>

At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

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

Commit messages:
 - Merge branch 'openjdk:master' into 8366461-mh-invoke
 - first pass

Changes: https://git.openjdk.org/jdk/pull/27059/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366461
  Stats: 538 lines in 68 files changed: 7 ins; 487 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/27059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059

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

From iklam at openjdk.org  Tue Sep  2 19:47:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Sep 2025 19:47:41 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v2]
In-Reply-To: <LNOhyyZoOqDheYd5ykb1ioYtW7Auwv7-AJ4PXtoZbJU=.85171d55-bb4c-4999-af15-f708fec3269c@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
 <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
 <LNOhyyZoOqDheYd5ykb1ioYtW7Auwv7-AJ4PXtoZbJU=.85171d55-bb4c-4999-af15-f708fec3269c@github.com>
Message-ID: <6d7OZxH790nUKN0jvkQ2kQjt_6sCTq336F9BrymQrQI=.bb547056-0167-41a4-b4af-cd4decd2e318@github.com>

On Mon, 1 Sep 2025 06:58:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Maybe the JBS title should be a bit more generic as you seem to be renaming many occurrences of "shared" not just the one listed.

The majority of the changes are about `is_shared` -> `in_aot_cache`. There are other changes like `_shared_metaspace_static_top` -> `_aot_metaspace_static_top`, but these are just implementation details.

This PR is one of the (many) subtasks for the "CDS" -> "AOT" renaming (main issue is [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473)).  My plan is to name each subtask to indicate its main purpose. Otherwise it will be difficult to be both precise and concise in the JBS title. 
- I.e., in this step I renamed some "shared" but left others, so I can't precisely describe that without writing a long essay. 
- If I used a generic title then it's difficult to tell the difference with other subtasks.

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

PR Comment: https://git.openjdk.org/jdk/pull/27016#issuecomment-3246575519

From dlong at openjdk.org  Tue Sep  2 19:55:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Sep 2025 19:55:58 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v2]
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <q666BSKYhNBydXX2dIxKJjrgi5BjsKZNWaUOygmZ16A=.39e96e03-3b9a-48c1-89a7-e7a1d67c1eba@github.com>

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

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

  arm32 build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27059/files
  - new: https://git.openjdk.org/jdk/pull/27059/files/4998cacc..303305ae

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

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

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

From coleenp at openjdk.org  Tue Sep  2 20:35:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Sep 2025 20:35:48 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

A few comments and suggestions for your next RFE.

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 344:

> 342:   volatile_nonstatic_field(ObjectMonitor,      _entry_list,                                   ObjectWaiter*)                         \
> 343:   volatile_nonstatic_field(ObjectMonitor,      _succ,                                         int64_t)                               \
> 344:   volatile_nonstatic_field(ObjectMonitor,      _stack_locker,                                 BasicLock*)                            \

There are some jvmci tests that check that the java side of jvmci matches, ie:

make test TEST=compiler/jvmci

src/hotspot/share/runtime/basicLock.hpp line 51:

> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
> 50: 
> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }

Also delete line 51 ?

src/hotspot/share/runtime/javaThread.cpp line 2007:

> 2005: #ifdef SUPPORT_MONITOR_COUNT
> 2006:   // Nothing to do. Just do some sanity check.
> 2007:   assert(_held_monitor_count == 0, "counter should not be used");

In further cleanup, can we now remove _held_monitor_count next?

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769:

> 767: 
> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated
> 769: // ObjectMonitor* when lightweight locking is used. It is used from contexts

I guess you don't need the phrase "when lightweight locking is used".

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 823:

> 821: ObjectMonitor* LightweightSynchronizer::inflate_into_object_header(oop object, ObjectSynchronizer::InflateCause cause, JavaThread* locking_thread, Thread* current) {
> 822: 
> 823:   // The JavaThread* locking_thread parameter is only used by lightweight locking and

Same here. suggestion:


// The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, or is suspended
// throughout the call by some other mechanism.

src/hotspot/share/runtime/synchronizer.cpp line 542:

> 540:   }
> 541:   ObjectMonitor* monitor;
> 542:   monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);

Declare and initialize on the same line:

ObjectMonitor* monitor = LightwightSynchronizer::inflate_locked_or_imse(obj...);

src/hotspot/share/runtime/synchronizer.cpp line 557:

> 555: 
> 556:   ObjectMonitor* monitor;
> 557:   monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);

same here with
ObjectMonitor* monitor = LIght ...

I think we should have another RFE to look at eliminating the middle call.  Call these in LIghtweightSynchronizer::notify, notifyAll and waitInterruptably directly and remove these functions.

src/hotspot/share/runtime/synchronizer.inline.hpp line 48:

> 46:   assert(current == Thread::current(), "must be");
> 47: 
> 48:     LightweightSynchronizer::enter(obj, lock, current);

In the further RFE, we should remove these dispatch functions too.

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

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3177963667
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317054927
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317063086
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317069783
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317072241
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317077253
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317084869
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317088830
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317095107

From dlong at openjdk.org  Tue Sep  2 20:52:32 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Sep 2025 20:52:32 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

Dean Long has updated the pull request incrementally with three additional commits since the last revision:

 - revert whitespace change
 - undo debug changes
 - cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27059/files
  - new: https://git.openjdk.org/jdk/pull/27059/files/303305ae..eac482a5

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

  Stats: 7 lines in 4 files changed: 1 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059

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

From iklam at openjdk.org  Tue Sep  2 21:02:35 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Sep 2025 21:02:35 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass* [v2]
In-Reply-To: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
Message-ID: <rKQUH9EHC6kcJdtNSHqrcLphRXPTFthc0lGnCHO4L_w=.8394e225-4a72-4365-93dd-d1b6304832f4@github.com>

> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code
> 
> 
> InstanceKlass* ik;
> InstanceKlass* s;
> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 
> s = ik->java_super(); // after JDK-8366024 
> 
> 
> to
> 
> 
> s = k->super();
> 
> 
> So you no longer need to do casting or need to understand what `java_super()` is.

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

  Added assert in heapInspection.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27037/files
  - new: https://git.openjdk.org/jdk/pull/27037/files/54236678..e1bac273

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

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

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

From iklam at openjdk.org  Tue Sep  2 21:02:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Sep 2025 21:02:36 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass* [v2]
In-Reply-To: <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
Message-ID: <zNcgbIql0ZAMOsmeUHKV0_DtcNqiqTKJeHPsZ4iP0cM=.7b612f18-a25f-47a8-997e-e8057cd19595@github.com>

On Tue, 2 Sep 2025 04:56:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added assert in heapInspection.cpp
>
> src/hotspot/share/memory/heapInspection.cpp line 405:
> 
>> 403:                                                       bool print_subclasses) {
>> 404:   // Set do_print for all superclasses of this class.
>> 405:   InstanceKlass* super = InstanceKlass::cast(cie->klass())->super();
> 
> Pre-existing, but if this cast is safe then `KlassInfoEntry::_klass` should be declared `InstanceKlass`. Otherwise this cast is not safe! Separate RFE for that.

I looked at the `KlassHierarchy` code and it looks at only instance klasses.

https://github.com/openjdk/jdk/blob/80fb7088a10136080d23ea93b4840f17d738500c/src/hotspot/share/memory/heapInspection.cpp#L318-L319

I added an assert to make this more apparent.

The `KlassInfoEntry` is used by other code that could sometimes store a non-instance klass. I'll leave it as is for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2317161232

From iklam at openjdk.org  Tue Sep  2 21:02:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Sep 2025 21:02:37 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass* [v2]
In-Reply-To: <mpjy68MrkQtbiGPi5Nx6-NewHDGnRkgSYk_qqzjbG8A=.6759b5e5-3946-4477-b5d0-b0cd291070d9@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
 <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com>
 <mpjy68MrkQtbiGPi5Nx6-NewHDGnRkgSYk_qqzjbG8A=.6759b5e5-3946-4477-b5d0-b0cd291070d9@github.com>
Message-ID: <01xQytgY2qniZkDfORqEoOeJ-PzOgU5-QLg-qumdzic=.99d732bb-9872-480e-9d2b-311069275ba3@github.com>

On Tue, 2 Sep 2025 11:43:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I think the term is "hides" not "shadows".  InstanceKlass::cast() is better - one additional check that super is always another InstanceKlass.
>
> Do we still need java_super ?

There are a few places that use it. Maybe we should look at these again in the future.


compiler dependencies:

./share/code/dependencies.cpp:      for (InstanceKlass* super = k->java_super(); super != nullptr; super = super->java_super()) {
./share/code/dependencies.cpp:      _klass = _klass->java_super();

subklass and sibling:

./share/oops/instanceKlass.cpp:    _current = _current->java_super(); // backtrack; no more sibling subclasses left
./share/oops/klass.cpp:  InstanceKlass* super = java_super();
./share/oops/klass.cpp:          && (super->java_super() == nullptr || !is_interface())),

Some general cases where you have a Klass but wants same super as in java.lang.Class::getSuperClass

./share/oops/klassVtable.cpp:  InstanceKlass* super = _klass->java_super();
./share/prims/jni.cpp:  // Rules of Class.getSuperClass as implemented by KLass::java_super:
./share/prims/jni.cpp:  Klass* super = k->java_super();
./share/prims/jni.cpp:         "java_super computation depends on interface, array, other super");
./share/services/heapDumper.cpp:  InstanceKlass* java_super = k->java_super();
./share/services/heapDumper.cpp:  assert(java_super != nullptr, "checking");
./share/services/heapDumper.cpp:  writer->write_classID(java_super);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2317159260

From iklam at openjdk.org  Tue Sep  2 21:08:25 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Sep 2025 21:08:25 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass* [v3]
In-Reply-To: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
Message-ID: <vDJPmg7qEVe9BtbcgtJ_CGeGhGEPC9wTz5WLebpGaw0=.20981d85-5e70-43a7-a8b9-4dd7b4b5940c@github.com>

> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code
> 
> 
> InstanceKlass* ik;
> InstanceKlass* s;
> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 
> s = ik->java_super(); // after JDK-8366024 
> 
> 
> to
> 
> 
> s = k->super();
> 
> 
> So you no longer need to do casting or need to understand what `java_super()` is.

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

  @dholmes-ora and @coleep comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27037/files
  - new: https://git.openjdk.org/jdk/pull/27037/files/e1bac273..dd0a3c5a

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

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

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

From iklam at openjdk.org  Tue Sep  2 21:08:25 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Sep 2025 21:08:25 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass* [v3]
In-Reply-To: <01xQytgY2qniZkDfORqEoOeJ-PzOgU5-QLg-qumdzic=.99d732bb-9872-480e-9d2b-311069275ba3@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
 <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com>
 <mpjy68MrkQtbiGPi5Nx6-NewHDGnRkgSYk_qqzjbG8A=.6759b5e5-3946-4477-b5d0-b0cd291070d9@github.com>
 <01xQytgY2qniZkDfORqEoOeJ-PzOgU5-QLg-qumdzic=.99d732bb-9872-480e-9d2b-311069275ba3@github.com>
Message-ID: <7fhuHDv6auOGm7Kj_QANCQ_eUB8ky4NRPAOxa-Gcn-M=.426a74ba-a359-4a6d-a796-aec9000001ff@github.com>

On Tue, 2 Sep 2025 20:57:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Do we still need java_super ?
>
> There are a few places that use it. Maybe we should look at these again in the future.
> 
> 
> compiler dependencies:
> 
> ./share/code/dependencies.cpp:      for (InstanceKlass* super = k->java_super(); super != nullptr; super = super->java_super()) {
> ./share/code/dependencies.cpp:      _klass = _klass->java_super();
> 
> subklass and sibling:
> 
> ./share/oops/instanceKlass.cpp:    _current = _current->java_super(); // backtrack; no more sibling subclasses left
> ./share/oops/klass.cpp:  InstanceKlass* super = java_super();
> ./share/oops/klass.cpp:          && (super->java_super() == nullptr || !is_interface())),
> 
> Some general cases where you have a Klass but wants same super as in java.lang.Class::getSuperClass
> 
> ./share/oops/klassVtable.cpp:  InstanceKlass* super = _klass->java_super();
> ./share/prims/jni.cpp:  // Rules of Class.getSuperClass as implemented by KLass::java_super:
> ./share/prims/jni.cpp:  Klass* super = k->java_super();
> ./share/prims/jni.cpp:         "java_super computation depends on interface, array, other super");
> ./share/services/heapDumper.cpp:  InstanceKlass* java_super = k->java_super();
> ./share/services/heapDumper.cpp:  assert(java_super != nullptr, "checking");
> ./share/services/heapDumper.cpp:  writer->write_classID(java_super);

I changed to `hides`. There are mentions of both `shadows` and `hides` in our comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2317171136

From iklam at openjdk.org  Tue Sep  2 21:08:26 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Sep 2025 21:08:26 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass* [v3]
In-Reply-To: <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <uJw7fHD_L4nX5J71er8F3gokpAkVJtBpYD8eLv78s5E=.715e1c4a-66af-4504-97ac-0b5ef931eeb1@github.com>
Message-ID: <ME5a_QsgcFJ-M56LH_KoH_pY0ftSajWPpvE8ARaUwRM=.afd77f27-794c-4601-9701-1ba19c0d992c@github.com>

On Tue, 2 Sep 2025 05:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dholmes-ora and @coleep comments
>
> src/hotspot/share/oops/klassVtable.cpp line 1574:
> 
>> 1572:   Klass* super = _klass->super();
>> 1573:   if (super != nullptr) {
>> 1574:     InstanceKlass* sk = InstanceKlass::cast(super); // why are we sure this is InstanceKlass??
> 
> I don't think it is guaranteed to be an IK. But AFAICS we don't actually need an IK here anyway, we should be able to use `super` directly.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2317170011

From vlivanov at openjdk.org  Tue Sep  2 21:11:46 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Sep 2025 21:11:46 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
Message-ID: <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>

On Tue, 2 Sep 2025 20:52:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert whitespace change
>  - undo debug changes
>  - cleanup

Nice cleanup! Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3178139499

From eastigeevich at openjdk.org  Tue Sep  2 21:45:03 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 2 Sep 2025 21:45:03 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v5]
In-Reply-To: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
Message-ID: <FX255eFGF9j00L-t0STNPnYPnFz69Ca6BDxNZsFQ6e4=.9358bf6e-2bff-43f6-ba4d-1029eafe76c6@github.com>

> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
> 
> This PR adds linking a class before the `copy_bytecodes` method is called.
> The PR also adds a regression test.
> 
> Tested fastdebug and release builds: Linux x86_64 and arm64
> - The reproducer from JDK-8277444 passed.
> - The regression test passed.
> - Tier1 - tier3 passed.

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

  Switch to macros HAS_PENDING_EXCEPTION, CLEAR_PENDING_EXCEPTION

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26863/files
  - new: https://git.openjdk.org/jdk/pull/26863/files/f5019d97..05207c6c

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

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

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

From eastigeevich at openjdk.org  Tue Sep  2 21:45:05 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 2 Sep 2025 21:45:05 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v4]
In-Reply-To: <1JIJRz2n7-MCQDwQhqWAMC5o1VQ0gYwLZ1jgkjQH8YU=.c06407bf-e13b-4e35-84f9-ab2f4154f754@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <ycjD7BT8p5lmyM44Tee59ugwvauK0t0E9z6bnzMsn88=.17ffe200-266e-4fbe-b726-86f96673d7c0@github.com>
 <1JIJRz2n7-MCQDwQhqWAMC5o1VQ0gYwLZ1jgkjQH8YU=.c06407bf-e13b-4e35-84f9-ab2f4154f754@github.com>
Message-ID: <oP5iwVZFq65IGrRmeSzgm2sX3lnT2uQLu-XKDThSckM=.3728ee8e-34c9-4de8-aeab-4ca082dd6ef7@github.com>

On Tue, 2 Sep 2025 12:04:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Evgeny Astigeevich 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 branch 'master' into JDK-8277444
>>  - Link classes before copy_bytecodes; Add regression test
>>  - Symplify comments; Get JavaThread::current in variable
>>  - Add missing include runtime/synchronizer.hpp
>>  - 8277444: Race condition on Instrumentation.retransformClasses() and class linking
>
> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 35:
> 
>> 33: #include "runtime/handles.inline.hpp"
>> 34: #include "runtime/signature.hpp"
>> 35: #include "runtime/synchronizer.hpp"
> 
> You don't need this include anymore.

Removed.

> src/hotspot/share/prims/jvmtiEnv.cpp line 3446:
> 
>> 3444:     current_thread->clear_pending_exception();
>> 3445:     return JVMTI_ERROR_INVALID_CLASS;
>> 3446:   }
> 
> Can you use the pattern:
> 
> 
>     JavaThread* THREAD = current_thread;
>     ... link_class(THREAD);
>     if (HAS_PENDING_EXCEPTION)
>       etc.

Switched to macros.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2317234764
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2317235161

From dlong at openjdk.org  Tue Sep  2 22:16:44 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Sep 2025 22:16:44 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>
Message-ID: <Qs9S_gOm2lAwk5iQCgkL_VglUnqegw7tuI8rjVdJ2hg=.6a5633c7-910f-4bb4-9866-ffb6e5c2b0d1@github.com>

On Tue, 2 Sep 2025 21:09:27 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - revert whitespace change
>>  - undo debug changes
>>  - cleanup
>
> Nice cleanup! Looks good.

Thanks @iwanowww !

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

PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3246957430

From syan at openjdk.org  Wed Sep  3 01:42:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 01:42:58 GMT
Subject: RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out
 after 60 second [v2]
In-Reply-To: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
References: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
Message-ID: <zrCRglBcSTgfFCC1xFq0ELecPlDygxp_pn2IXEoftno=.6166035b-243b-4245-aa04-a8547d1d1e76@github.com>

> Hi all,
> 
> Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . After JDK-8260555 change the timeout factor from 4 to 1, so this timeout value should be ajusted.
> 
> Change has been verified locally, risk is low.

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

  Use addDebuggeeOptions(-Xmx64) to make test run quickly, instead of add timeout value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27055/files
  - new: https://git.openjdk.org/jdk/pull/27055/files/59f3b769..97fa547c

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

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

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

From syan at openjdk.org  Wed Sep  3 01:49:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 01:49:04 GMT
Subject: RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out
 after 60 second [v3]
In-Reply-To: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
References: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
Message-ID: <miskMVDUEeMwirE4dN5H4z2H80qIZD0EjokSXMlFe3g=.9045e8e0-a1ac-481e-b759-ab10bb64425c@github.com>

> Hi all,
> 
> Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . After JDK-8260555 change the timeout factor from 4 to 1, so this timeout value should be ajusted.
> 
> Change has been verified locally, risk is low.

SendaoYan 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 branch 'openjdk:master' into jbs8366694
 - Use addDebuggeeOptions(-Xmx64) to make test run quickly, instead of add timeout value
 - 8366694: Test JdbStopInNotificationThreadTest.java timed out after 60 second

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27055/files
  - new: https://git.openjdk.org/jdk/pull/27055/files/97fa547c..2196213c

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

  Stats: 831 lines in 41 files changed: 270 ins; 348 del; 213 mod
  Patch: https://git.openjdk.org/jdk/pull/27055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27055/head:pull/27055

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

From syan at openjdk.org  Wed Sep  3 01:57:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 01:57:42 GMT
Subject: RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out
 after 60 second [v3]
In-Reply-To: <3fIKMR76GJ1JKPGZrmd4RXydp4pj92AcmYdvRjJtclc=.45344458-c4e8-4162-abbf-5bd19ccb9cd3@github.com>
References: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
 <3fIKMR76GJ1JKPGZrmd4RXydp4pj92AcmYdvRjJtclc=.45344458-c4e8-4162-abbf-5bd19ccb9cd3@github.com>
Message-ID: <xK-D9ygZc3OYqQANGzQXEmWqsKy1t4o8ocotj2CSNDw=.e61c621d-bdc5-4708-999c-9d6965dd3626@github.com>

On Tue, 2 Sep 2025 18:15:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan 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 branch 'openjdk:master' into jbs8366694
>>  - Use addDebuggeeOptions(-Xmx64) to make test run quickly, instead of add timeout value
>>  - 8366694: Test JdbStopInNotificationThreadTest.java timed out after 60 second
>
> test/jdk/com/sun/jdi/lib/jdb/Jdb.java line 80:
> 
>> 78:     private static final long sleepTime = 1000;
>> 79:     // max time to wait for  jdb output (in ms)
>> 80:     private static final long timeout = Utils.adjustTimeout(120000);
> 
> The way this is implemented is unfortunate. Jdb responses should normally be fairly quick. However, in this test the response doesn't happen until 10% of the java heap has been allocated, and I guess that can be slow sometimes. For some reason the test only allocates 8k at a time, and does a 100ms sleep every 1000 allocations. So now because of this one test, all tests need an unnecessary long timeout. I'm not sure of the reason for the sleep, but in general my suggestion would be to speed up how quickly the test gets to the point of 10% of the java heap being in use.  I think using a smaller heap would be the best choice here. Updating the main method to the following should work:
> 
> 
>     public static void main(String argv[]) {
>         JdbTest test = new JdbStopInNotificationThreadTest();
>         test.launchOptions.addVMOptions("-Xmx64m")
>         test.run();
>     }
> 
> 
> Possibly 64m is too small. Remember the trigger happens at 10% of that size, so will happen when 6.4m is allocated. Hopefully that isn't until after the debuggee is actually into the memory allocation code and not before. You may need to adjust higher.

Thanks for your suggestions.
It does very pity to make all the jdb tests have long timeout. Use '-Xmx64' to make java heap allocated finish quick is more graceful solution. I have updated to use '-Xmx64' and it works.

Change has been verified localy on linux-x64.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27055#discussion_r2317568271

From syan at openjdk.org  Wed Sep  3 03:23:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 03:23:16 GMT
Subject: RFR: 8366695: Test
 sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out
Message-ID: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>

Hi all,

Test sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java create 10 java processes, and maybe this cause this test timed out when run this test with other jtreg tests concurrently. Though the run time statistics shows that it do not run timed out, but it did on the brink of timed out.

After JDK-8260555 change the default jtreg timeout factor from 4 to 1, I think it's necessary to change the timeout value in sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java from 120(default value) to 240, to avoid this test run timed out intermittently.

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

Commit messages:
 - 8366695: Test sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out

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

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

From cjplummer at openjdk.org  Wed Sep  3 05:38:42 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Sep 2025 05:38:42 GMT
Subject: RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out
 after 60 second [v3]
In-Reply-To: <miskMVDUEeMwirE4dN5H4z2H80qIZD0EjokSXMlFe3g=.9045e8e0-a1ac-481e-b759-ab10bb64425c@github.com>
References: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
 <miskMVDUEeMwirE4dN5H4z2H80qIZD0EjokSXMlFe3g=.9045e8e0-a1ac-481e-b759-ab10bb64425c@github.com>
Message-ID: <AlotBFTx9SeDiaSs4gYRSt-LoYxsFvGI97IXZspE98E=.d09be3b3-8a21-4de8-ac52-38b9424b9f19@github.com>

On Wed, 3 Sep 2025 01:49:04 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . 
>> 
>> This PR add '-Xmx64' to make debugee JVM to finish the java heap allocation quickly.
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan 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 branch 'openjdk:master' into jbs8366694
>  - Use addDebuggeeOptions(-Xmx64) to make test run quickly, instead of add timeout value
>  - 8366694: Test JdbStopInNotificationThreadTest.java timed out after 60 second

Looks good. Thanks for the update.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27055#pullrequestreview-3179008953

From mhaessig at openjdk.org  Wed Sep  3 07:17:44 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 3 Sep 2025 07:17:44 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
Message-ID: <j17HsQMH4wjiC9yAOssV1Ivx6dOMyUw_dgT-Q0KlV-c=.b7523e4d-515f-4384-adb3-cc3c9763db5c@github.com>

On Tue, 2 Sep 2025 20:52:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert whitespace change
>  - undo debug changes
>  - cleanup

Thank you for cleaning this up, @dean-long. I just have a drive-by comment.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java line 372:

> 370:         // DEBUG_ONLY(verifyDeoptriginalPc(senderNm, raw_unextendedSp));
> 371:       }
> 372:     }

`<arch>Frame.java adjustUnextendedSP()` do not seem to do anything? Perhaps these could be cleaned up as well?

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

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3179245014
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2317990499

From syan at openjdk.org  Wed Sep  3 07:27:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 07:27:42 GMT
Subject: RFR: 8366695: Test
 sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out
In-Reply-To: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
References: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
Message-ID: <-bmacKFFWlgnmhzY2PZ3V6G1GuDx6FiVXK9_XXD9j7c=.be70d03f-a8a2-48ef-9f1f-a040889711e7@github.com>

On Wed, 3 Sep 2025 03:18:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java create 10 java processes, and maybe this cause this test timed out when run this test with other jtreg tests concurrently. Though the run time statistics shows that it do not run timed out, but it did on the brink of timed out.
> 
> After JDK-8260555 change the default jtreg timeout factor from 4 to 1, I think it's necessary to change the timeout value in sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java from 120(default value) to 240, to avoid this test run timed out intermittently.

GHA report test jdk/jshell/ToolLocalSimpleTest.java fails on windows-x64, this fails has been recorded by [JDK-8366582](https://bugs.openjdk.org/browse/JDK-8366582), it's unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27064#issuecomment-3248013271

From ayang at openjdk.org  Wed Sep  3 07:57:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Sep 2025 07:57:46 GMT
Subject: RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out
 after 60 second [v3]
In-Reply-To: <miskMVDUEeMwirE4dN5H4z2H80qIZD0EjokSXMlFe3g=.9045e8e0-a1ac-481e-b759-ab10bb64425c@github.com>
References: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
 <miskMVDUEeMwirE4dN5H4z2H80qIZD0EjokSXMlFe3g=.9045e8e0-a1ac-481e-b759-ab10bb64425c@github.com>
Message-ID: <ebBvaTHgrEEcRQ9ssqfABOxsd3NBxzv-R83SXPtijb0=.c753a7c5-948c-44d7-bbab-18dbe5273782@github.com>

On Wed, 3 Sep 2025 01:49:04 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . 
>> 
>> This PR add '-Xmx64' to make debugee JVM to finish the java heap allocation quickly.
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan 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 branch 'openjdk:master' into jbs8366694
>  - Use addDebuggeeOptions(-Xmx64) to make test run quickly, instead of add timeout value
>  - 8366694: Test JdbStopInNotificationThreadTest.java timed out after 60 second

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27055#pullrequestreview-3179406348

From aboldtch at openjdk.org  Wed Sep  3 09:51:45 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Sep 2025 09:51:45 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <0CMB0g0_Ru1hF5l2NA194kD1ouNwMXrB1667Uvl9mFQ=.b6834c47-be53-41bb-b726-2e282517d6bc@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Nothing obvious seems to be missing from the removal. And the changes look correct.

As @coleenp already mentioned there is even more code now that is effectively unused. Mostly to do with legacy + loom interactions. But I think it is fine to remove that in a follow up RFE.

Similarly there are some nomenclature that should be updated, but I know you have expressed wanting to do that in a follow up RFE as well.

I think it the main refactoring that are left are cleaning up the Synchronizer APIs, unifying some functions etc. 

_As for unifying LightweightSynchronizer with the ObjectSynchronizer, there might be an opportunity to let ObjectSynchronizer define the general API used by the rest of the VM to interact with the locking subsystem. And let LightweightSynchronizer contain all of the implementation. This could including moving the locking specific implementation details of relocking, deopting etc. behind an interface, decoupling them, and avoiding leaking implementation._

src/hotspot/share/runtime/basicLock.hpp line 51:

> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
> 50: 
> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }

The `badDispHeaderDeopt` and `badDispHeaderOSR` constants should also be renamed.

src/hotspot/share/runtime/synchronizer.cpp line 634:

> 632: }
> 633: 
> 634: static intptr_t install_hash_code(Thread* current, oop obj) {

A future RFE could potentially simplify and unify this with `FastHashCode`

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3179315618
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2318059361
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2318041555

From coleenp at openjdk.org  Wed Sep  3 11:36:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Sep 2025 11:36:46 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v5]
In-Reply-To: <FX255eFGF9j00L-t0STNPnYPnFz69Ca6BDxNZsFQ6e4=.9358bf6e-2bff-43f6-ba4d-1029eafe76c6@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <FX255eFGF9j00L-t0STNPnYPnFz69Ca6BDxNZsFQ6e4=.9358bf6e-2bff-43f6-ba4d-1029eafe76c6@github.com>
Message-ID: <8gZJSnHgfc8RwLlaObVBXJ7ubs9mI1MDq3ZL8ZbuQ9Q=.1f08be90-5896-4620-aed7-f7f81958beae@github.com>

On Tue, 2 Sep 2025 21:45:03 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds linking a class before the `copy_bytecodes` method is called.
>> The PR also adds a regression test.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - The regression test passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to macros HAS_PENDING_EXCEPTION, CLEAR_PENDING_EXCEPTION

This looks good now.  Thank you for your patience while we found the right solution.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3180219072

From coleenp at openjdk.org  Wed Sep  3 11:41:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Sep 2025 11:41:44 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass* [v3]
In-Reply-To: <vDJPmg7qEVe9BtbcgtJ_CGeGhGEPC9wTz5WLebpGaw0=.20981d85-5e70-43a7-a8b9-4dd7b4b5940c@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <vDJPmg7qEVe9BtbcgtJ_CGeGhGEPC9wTz5WLebpGaw0=.20981d85-5e70-43a7-a8b9-4dd7b4b5940c@github.com>
Message-ID: <Qn6AlA3zHuAwEvCmE2GBQMfE9LkvSF5FhvZZs3qDtcU=.fd45e7d9-52c3-4840-ab2e-563b6a15ca72@github.com>

On Tue, 2 Sep 2025 21:08:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code
>> 
>> 
>> InstanceKlass* ik;
>> InstanceKlass* s;
>> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 
>> s = ik->java_super(); // after JDK-8366024 
>> 
>> 
>> to
>> 
>> 
>> s = k->super();
>> 
>> 
>> So you no longer need to do casting or need to understand what `java_super()` is.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora and @coleep comments

Looks good.  This will help with InstanceKlass casting.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27037#pullrequestreview-3180231376

From lkorinth at openjdk.org  Wed Sep  3 12:39:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 3 Sep 2025 12:39:00 GMT
Subject: Integrated: 8366803: Bump timeout on
 sun/tools/jhsdb/BasicLauncherTest.java
Message-ID: <XX_uiFj98UoQ1IaYggKUWW0dcUjsJzZhB5UrdpJ5Dbs=.80060099-3eef-4c1c-b97f-fc04a1ac770a@github.com>

Just need the old timeout value

result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-26+14-1410\windows-x64-debug.jdk\jdk-26\fastdebug\bin\java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 178895ms).

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

Commit messages:
 - 8366803: Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java

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

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

From stefank at openjdk.org  Wed Sep  3 12:39:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Sep 2025 12:39:00 GMT
Subject: Integrated: 8366803: Bump timeout on
 sun/tools/jhsdb/BasicLauncherTest.java
In-Reply-To: <XX_uiFj98UoQ1IaYggKUWW0dcUjsJzZhB5UrdpJ5Dbs=.80060099-3eef-4c1c-b97f-fc04a1ac770a@github.com>
References: <XX_uiFj98UoQ1IaYggKUWW0dcUjsJzZhB5UrdpJ5Dbs=.80060099-3eef-4c1c-b97f-fc04a1ac770a@github.com>
Message-ID: <BeeXZsWS0calr1v5Tvh3sq2Mjsqd5Na5dfsei4RpdN8=.61da4e45-4f90-4780-a612-e1c94b33b258@github.com>

On Wed, 3 Sep 2025 12:32:17 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Just need the old timeout value
> 
> result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-26+14-1410\windows-x64-debug.jdk\jdk-26\fastdebug\bin\java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 178895ms).

Marked as reviewed by stefank (Reviewer).

This can be considered "trivial".

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

PR Review: https://git.openjdk.org/jdk/pull/27070#pullrequestreview-3180433547
PR Comment: https://git.openjdk.org/jdk/pull/27070#issuecomment-3249065789

From lkorinth at openjdk.org  Wed Sep  3 12:39:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 3 Sep 2025 12:39:00 GMT
Subject: Integrated: 8366803: Bump timeout on
 sun/tools/jhsdb/BasicLauncherTest.java
In-Reply-To: <XX_uiFj98UoQ1IaYggKUWW0dcUjsJzZhB5UrdpJ5Dbs=.80060099-3eef-4c1c-b97f-fc04a1ac770a@github.com>
References: <XX_uiFj98UoQ1IaYggKUWW0dcUjsJzZhB5UrdpJ5Dbs=.80060099-3eef-4c1c-b97f-fc04a1ac770a@github.com>
Message-ID: <zdaNr37EFjPkVv_v7TxoXU8NKFPtU5AnOlgL9v4fBis=.6ce1c235-5803-4310-85d9-d411b852e4d2@github.com>

On Wed, 3 Sep 2025 12:32:17 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Just need the old timeout value
> 
> result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-26+14-1410\windows-x64-debug.jdk\jdk-26\fastdebug\bin\java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 178895ms).

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27070#issuecomment-3249070093

From lkorinth at openjdk.org  Wed Sep  3 12:39:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 3 Sep 2025 12:39:00 GMT
Subject: Integrated: 8366803: Bump timeout on
 sun/tools/jhsdb/BasicLauncherTest.java
In-Reply-To: <XX_uiFj98UoQ1IaYggKUWW0dcUjsJzZhB5UrdpJ5Dbs=.80060099-3eef-4c1c-b97f-fc04a1ac770a@github.com>
References: <XX_uiFj98UoQ1IaYggKUWW0dcUjsJzZhB5UrdpJ5Dbs=.80060099-3eef-4c1c-b97f-fc04a1ac770a@github.com>
Message-ID: <F2Bd1cGbHLZROlImPMi7oemykq1IKUjKLWsB9ckwDx4=.2fc61fe8-5153-4350-b8f1-4cab77b61463@github.com>

On Wed, 3 Sep 2025 12:32:17 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Just need the old timeout value
> 
> result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-26+14-1410\windows-x64-debug.jdk\jdk-26\fastdebug\bin\java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 178895ms).

This pull request has now been integrated.

Changeset: 3b2f3e53
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b2f3e53d7f27653c3d4608b141aed6a84829aa8
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8366803: Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java

Reviewed-by: stefank

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

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

From lmesnik at openjdk.org  Wed Sep  3 15:47:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 3 Sep 2025 15:47:43 GMT
Subject: RFR: 8366695: Test
 sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out
In-Reply-To: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
References: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
Message-ID: <rOpJ1MxE5Kvp0fuwYe_A9yzgJiTWAucOlS9KUq0bmV0=.b01086f3-1c1c-4208-bbf2-47f403051250@github.com>

On Wed, 3 Sep 2025 03:18:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java create 10 java processes, and maybe this cause this test timed out when run this test with other jtreg tests concurrently. Though the run time statistics shows that it do not run timed out, but it did on the brink of timed out.
> 
> After JDK-8260555 change the default jtreg timeout factor from 4 to 1, I think it's necessary to change the timeout value in sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java from 120(default value) to 240, to avoid this test run timed out intermittently.

It would be really great to understand why the time might be so different for this test. However, it might be to much effort.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27064#pullrequestreview-3181268118

From lmesnik at openjdk.org  Wed Sep  3 15:48:45 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 3 Sep 2025 15:48:45 GMT
Subject: RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out
 after 60 second [v3]
In-Reply-To: <miskMVDUEeMwirE4dN5H4z2H80qIZD0EjokSXMlFe3g=.9045e8e0-a1ac-481e-b759-ab10bb64425c@github.com>
References: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
 <miskMVDUEeMwirE4dN5H4z2H80qIZD0EjokSXMlFe3g=.9045e8e0-a1ac-481e-b759-ab10bb64425c@github.com>
Message-ID: <rHZuatuE-w8M2XPVyVHAZeWw31Oxx3tPMqZw-tYWrko=.fbd7d857-af3a-4716-9ca0-1cf81d193a4c@github.com>

On Wed, 3 Sep 2025 01:49:04 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . 
>> 
>> This PR add '-Xmx64' to make debugee JVM to finish the java heap allocation quickly.
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan 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 branch 'openjdk:master' into jbs8366694
>  - Use addDebuggeeOptions(-Xmx64) to make test run quickly, instead of add timeout value
>  - 8366694: Test JdbStopInNotificationThreadTest.java timed out after 60 second

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27055#pullrequestreview-3181271745

From lmesnik at openjdk.org  Wed Sep  3 15:49:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 3 Sep 2025 15:49:44 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <xBXI_F-jszTe_2APvvraAs2E5mNFDrPI96aTgTQz9q8=.1bc1774f-39f9-4c65-8f0f-6bc3644f323e@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

svc part looks good.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3181274100

From duke at openjdk.org  Wed Sep  3 15:54:22 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 15:54:22 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count
 after gc events
Message-ID: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>

### Summary

The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.

### Performance
The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)

#### Default workload:
ObjectCountAfterGC disabled (master branch):
`[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
`[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
`[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
`[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
`[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
`[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
`[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`

ObjectCountAfterGC disabled (feature branch):
`[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
`[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
`[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
`[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
`[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
`[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`

ObjectCountAfterGC enabled (feature branch)
`[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
`[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
`[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
`[807.299s][info][gc,stats    ] Concurrent Marking             =    1.676 s (a =   167595 us)`
`[807.299s][info][gc,stats    ] Pause Final Mark (G)           =    0.005 s (a =      537 us)`
`[807.299s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      430 us)`

#### Stress workload:
ObjectCountAfterGC disabled (master branch):
`[1213.361s][info][gc,stats    ] Pause Init Mark (G)            =    0.023 s (a =      232 us)`
`[1213.361s][info][gc,stats    ] Pause Init Mark (N)            =    0.009 s (a =       85 us)`
`[1213.361s][info][gc,stats    ] Concurrent Mark Roots          =    0.252 s (a =     2521 us)`
`[1213.361s][info][gc,stats    ] Concurrent Marking             =   17.635 s (a =   176354 us) `
`[1213.361s][info][gc,stats    ] Pause Final Mark (G)           =    0.065 s (a =      651 us)`
`[1213.361s][info][gc,stats    ] Pause Final Mark (N)           =    0.049 s (a =      493 us)`

ObjectCountAfterGC disabled (feature branch):
`[1213.626s][info][gc,stats    ] Pause Init Mark (G)            =    0.023 s (a =      234 us)`
`[1213.626s][info][gc,stats    ] Pause Init Mark (N)            =    0.009 s (a =       86 us)`
`[1213.626s][info][gc,stats    ] Concurrent Mark Roots          =    0.265 s (a =     2645 us)`
`[1213.626s][info][gc,stats    ] Concurrent Marking             =   17.747 s (a =   177468 us)`
`[1213.626s][info][gc,stats    ] Pause Final Mark (G)           =    0.043 s (a =      431 us)`
`[1213.626s][info][gc,stats    ] Pause Final Mark (N)           =    0.036 s (a =      362 us)`

ObjectCountAfterGC enabled (feature branch):
`[1213.699s][info][gc,stats    ] Pause Init Mark (G)            =    0.020 s (a =      202 us) `
`[1213.699s][info][gc,stats    ] Pause Init Mark (N)            =    0.008 s (a =       83 us)`
`[1213.699s][info][gc,stats    ] Concurrent Mark Roots          =    0.340 s (a =     3404 us)`
`[1213.699s][info][gc,stats    ] Concurrent Marking             =   17.929 s (a =   179289 us)`
`[1213.699s][info][gc,stats    ] Pause Final Mark (G)           =    0.049 s (a =      492 us)`
`[1213.699s][info][gc,stats    ] Pause Final Mark (N)           =    0.040 s (a =      405 us)`

### Testing
Tested changes with GHA, jtreg tier1 JFR, and hotspot_gc. CodePipeline internal perf and stress test succeeded.

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

Commit messages:
 - Changed comment, included another guard
 - Removing whitespace
 - Merge master
 - Merge master
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/shen-aggregate-closure
 - Comment on why return value was changed to bool
 - Deleted objectCountEventSender.inline.hpp
 - Merging master
 - Reverting changes back to original state for some files
 - Merge branch '8366122/shen-object-count-after-gc' into test/shen-aggregate-closure
 - ... and 121 more: https://git.openjdk.org/jdk/compare/efb81daf...9552c62b

Changes: https://git.openjdk.org/jdk/pull/26977/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366122
  Stats: 307 lines in 24 files changed: 252 ins; 28 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/26977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26977/head:pull/26977

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

From kdnilsen at openjdk.org  Wed Sep  3 15:54:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 3 Sep 2025 15:54:22 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <Ag8YUYFFc19FEHoCz3qtzErmImHLsfsPy7DLJ5uwKtI=.6a0d4c07-6cf6-4da7-9893-eea75091167e@github.com>

On Thu, 28 Aug 2025 01:30:39 GMT, pf0n <duke at openjdk.org> wrote:

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

I concur with comments by Ramki.

Also, I wonder if you can add to the summary overview a description of how much additional memory is required to enable concurrent object counting.  I believe there is a new thread-local table (how large is this?) for each GC worker thread.  I think service threads do not need this table.  Can you clarify?

The performance numbers quoted in the performance summary above are for Shennadoah satb mode, or for generational mode?  Maybe both should be reported.

src/hotspot/share/gc/shared/gcTrace.inline.hpp line 12:

> 10: 
> 11: // The ObjectCountEventSenderClosure will determine if only the ObjectCount
> 12: // event will be emitted instead of ObjectCountAfterGC. If false, then both

If "what" is false?  This comment is not clear.  Are you speaking of the SeparateEventEmission template parameter?

I think the use of future-tense "will" also makes this comment confusing.  Can you write this in present tense?

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

PR Review: https://git.openjdk.org/jdk/pull/26977#pullrequestreview-3166929412
PR Comment: https://git.openjdk.org/jdk/pull/26977#issuecomment-3235270167
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308805732

From wkemper at openjdk.org  Wed Sep  3 15:54:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Sep 2025 15:54:23 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>

On Thu, 28 Aug 2025 01:30:39 GMT, pf0n <duke at openjdk.org> wrote:

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

Left a few superficial suggestions. My big question is what work remains for this event to also work with the generational mode?

src/hotspot/share/gc/shared/gcTrace.hpp line 136:

> 134:   void report_gc_reference_stats(const ReferenceProcessorStats& rp) const;
> 135:   void report_object_count_after_gc(BoolObjectClosure* object_filter, WorkerThreads* workers) NOT_SERVICES_RETURN;
> 136:   // Report object count by not performing a heap inspection. This method will

s/by not/without

src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 179:

> 177:   // Use object counting closure if ObjectCount or ObjectCountAfterGC event is enabled.
> 178:   const bool object_count_enabled = ObjectCountEventSender::should_send_event();
> 179:   if (object_count_enabled && !ShenandoahHeap::heap()->mode()->is_generational()) {

Can the generational mode support this? It can also perform a _global_ collection.

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 130:

> 128:       // Create the KlassInfoTable for Shenandoah only if JFR is enabled.
> 129: #if INCLUDE_JFR
> 130:       KlassInfoTable cit(false);

Might consider a `CADR` helper class here (Constructor Acquires, Destructor Releases). There are a lot of lines of code between the two `set_cit` calls (and the second one isn't guarded by `INCLUDE_JFR`).

src/hotspot/share/memory/heapInspection.hpp line 33:

> 31: #include "oops/objArrayOop.hpp"
> 32: #include "oops/oop.hpp"
> 33: #include "runtime/mutex.hpp"

Does this need to be in the header?

src/hotspot/share/runtime/mutexLocker.hpp line 90:

> 88: extern Monitor* Notify_lock;                     // a lock used to synchronize the start-up of the vm
> 89: extern Mutex*   ExceptionCache_lock;             // a lock used to synchronize exception cache updates
> 90: extern Mutex*   TableMerge_lock;                 // a lock used to synchronize merging a thread-local table into a global table

Might call this `ObjectCountMerge_lock` and describe its usage as `merging a thread local object count`. There are many `Tables` in the JVM (SymbolTable, InternedStrings, etc.).

test/jdk/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithShenandoah.java line 11:

> 9:  *           & vm.opt.ExplicitGCInvokesConcurrent != true
> 10:  * @library /test/lib /test/jdk
> 11:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -XX:+UseShenandoahGC -XX:MarkSweepDeadRatio=0 -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:+IgnoreUnrecognizedVMOptions jdk.jfr.event.gc.objectcount.TestObjectCountAfterGCEventWithShenandoah

Are all of these flags necessary to run this test? Can we pare any unnecessary options?

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26977#pullrequestreview-3178372422
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317339492
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317344826
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317348710
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317355707
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317358657
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317360739

From ysr at openjdk.org  Wed Sep  3 15:54:24 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 3 Sep 2025 15:54:24 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <SybYT5LlWxR7Xj8RIG8Q5FA0oVKQXZ29HqR9C482bQQ=.31b680fb-2ae5-4401-9838-032a22c77451@github.com>

On Thu, 28 Aug 2025 01:30:39 GMT, pf0n <duke at openjdk.org> wrote:

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

@pf0n : 

1. For the performance numbers, use the final summaries (in the gc log) of quartile and range of time distributions of the pauses and the phases to better reflect the impact on collections throughout the entire run, rather than for specific spot collections.
2. For completeness in the PR description and to help reviewers, please comment upon whether, when the event is enabled, the counting closures are used also for collections other than concurrent ones and where the events are emitted in those cases.

Thanks!

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 129:

> 127:     if (gc_requested) {
> 128:       // Create the KlassInfoTable for Shenandoah only if JFR is enabled.
> 129:       #if INCLUDE_JFR

Here and elsewhere:
1. for single line pre-proc directives, consider the use of `JFR_ONLY()`.
2. For multi-line pre-proc directives, unindent all the way to the zeroth column, in keeping with hotspot style precedent, even though newer pre-processors accept indented directives.

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 232:

> 230:   volatile size_t _committed;
> 231:   shenandoah_padding(1);
> 232:   KlassInfoTable* _cit;

Move the comment from line 257 below to before this place.

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 256:

> 254:   void set_soft_max_capacity(size_t v);
> 255: 
> 256:   // Create Shenandoah's KlassInfoTable.

Not create, but set?

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 260:

> 258:   inline void set_cit(KlassInfoTable* cit);
> 259: 
> 260:   // Return Shenandoah's KlassInfoTable.

Put these together and use one comment like:


// Setter & accessor for class histogram

src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 653:

> 651: inline void ShenandoahHeap::set_cit(KlassInfoTable* cit) {
> 652:   assert((_cit == nullptr && cit != nullptr) ||
> 653:     (_cit != nullptr && cit == nullptr), "Initialize once & clear once");

The assert message isn't accurate for your current usage. Suggest splitting into two asserts with a suitable message:

assert(_cit == nullptr || cit == nullptr, "Overwriting an existing histogram");
assert(_cit != nullptr || cit != nullptr, "Already cleared");

src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 658:

> 656: 
> 657: inline KlassInfoTable* ShenandoahHeap::get_cit() {
> 658:   assert(_cit != nullptr, "KlassInfoTable for Shenandoah should be initialized");

Change the message to: "KlassInfoTable is null"
(suggestion is to avoid "initialized" here, since the value is repeatedly toggled from a pointer to stack allocated klass info table to null and back).

Essentially the heap is used as a post-office-box to pass a handle to a stack allocated object to worker threads using the object.

src/hotspot/share/gc/shenandoah/shenandoahMark.cpp line 72:

> 70:     mark_loop_work<Closure, GENERATION, CANCELLABLE, STRING_DEDUP>(&cl, ld, w, t, req);
> 71:   } else {
> 72:     #if INCLUDE_JFR

unindent (left-justify to 0th column)

src/hotspot/share/gc/shenandoah/shenandoahMark.hpp line 60:

> 58: public:
> 59:   template<class T, ShenandoahGenerationType GENERATION>
> 60:   static inline bool mark_through_ref(T* p, ShenandoahObjToScanQueue* q, ShenandoahObjToScanQueue* old_q, ShenandoahMarkingContext* const mark_context, bool weak);

document the semantics of the method's return value here and everywhere where a bool return replaces a previously void return.

src/hotspot/share/runtime/mutexLocker.hpp line 90:

> 88: extern Monitor* Notify_lock;                     // a lock used to synchronize the start-up of the vm
> 89: extern Mutex*   ExceptionCache_lock;             // a lock used to synchronize exception cache updates
> 90: extern Mutex*   TableMerge_lock;                 // a lock used to synchronize merging of thread-local KlassInfoTables

nit: `... merging a thread-local into a global table`

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

PR Comment: https://git.openjdk.org/jdk/pull/26977#issuecomment-3235400211
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308906242
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308907269
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308907857
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308910727
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308919955
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308923148
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308926296
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308929362
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308937729

From duke at openjdk.org  Wed Sep  3 15:54:24 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 15:54:24 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <Ag8YUYFFc19FEHoCz3qtzErmImHLsfsPy7DLJ5uwKtI=.6a0d4c07-6cf6-4da7-9893-eea75091167e@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <Ag8YUYFFc19FEHoCz3qtzErmImHLsfsPy7DLJ5uwKtI=.6a0d4c07-6cf6-4da7-9893-eea75091167e@github.com>
Message-ID: <LSyHUVUcJ2sDAvb3MTi5tF06TB5LALX_38NlF42Om9Y=.b934e163-7478-4138-b45d-c0c7aecc7958@github.com>

On Thu, 28 Aug 2025 23:49:20 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> ### Summary
>> 
>> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
>> 
>> ### Performance
>> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
>> 
>> #### Default workload:
>> ObjectCountAfterGC disabled (master branch):
>> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
>> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
>> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
>> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
>> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
>> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
>> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
>> 
>> ObjectCountAfterGC disabled (feature branch):
>> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
>> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
>> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
>> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
>> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
>> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
>> 
>> ObjectCountAfterGC enabled (feature branch)
>> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
>> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
>> `[807.299s][info][gc,stats    ] Concurrent Mark Roots       ...
>
> src/hotspot/share/gc/shared/gcTrace.inline.hpp line 12:
> 
>> 10: 
>> 11: // The ObjectCountEventSenderClosure will determine if only the ObjectCount
>> 12: // event will be emitted instead of ObjectCountAfterGC. If false, then both
> 
> If "what" is false?  This comment is not clear.  Are you speaking of the SeparateEventEmission template parameter?
> 
> I think the use of future-tense "will" also makes this comment confusing.  Can you write this in present tense?

I'll remove this template parameter, since it won't be needed for the ObjectCountAfterGC PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2312857523

From duke at openjdk.org  Wed Sep  3 15:54:24 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 15:54:24 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
Message-ID: <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>

On Tue, 2 Sep 2025 22:46:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> ### Summary
>> 
>> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
>> 
>> ### Performance
>> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
>> 
>> #### Default workload:
>> ObjectCountAfterGC disabled (master branch):
>> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
>> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
>> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
>> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
>> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
>> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
>> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
>> 
>> ObjectCountAfterGC disabled (feature branch):
>> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
>> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
>> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
>> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
>> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
>> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
>> 
>> ObjectCountAfterGC enabled (feature branch)
>> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
>> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
>> `[807.299s][info][gc,stats    ] Concurrent Mark Roots       ...
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 179:
> 
>> 177:   // Use object counting closure if ObjectCount or ObjectCountAfterGC event is enabled.
>> 178:   const bool object_count_enabled = ObjectCountEventSender::should_send_event();
>> 179:   if (object_count_enabled && !ShenandoahHeap::heap()->mode()->is_generational()) {
> 
> Can the generational mode support this? It can also perform a _global_ collection.

It could be possible to extend the object counting closure for GenShen. I would have to look more deep into where the closure can be used.

> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 130:
> 
>> 128:       // Create the KlassInfoTable for Shenandoah only if JFR is enabled.
>> 129: #if INCLUDE_JFR
>> 130:       KlassInfoTable cit(false);
> 
> Might consider a `CADR` helper class here (Constructor Acquires, Destructor Releases). There are a lot of lines of code between the two `set_cit` calls (and the second one isn't guarded by `INCLUDE_JFR`).

I'll look into that. Thanks for pointing out the unguarded `set_cit`.

> src/hotspot/share/memory/heapInspection.hpp line 33:
> 
>> 31: #include "oops/objArrayOop.hpp"
>> 32: #include "oops/oop.hpp"
>> 33: #include "runtime/mutex.hpp"
> 
> Does this need to be in the header?

I had an error in GHA during my early implementation, so I included that header. I'll remove and test to see if it is needed or not.

> test/jdk/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithShenandoah.java line 11:
> 
>> 9:  *           & vm.opt.ExplicitGCInvokesConcurrent != true
>> 10:  * @library /test/lib /test/jdk
>> 11:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -XX:+UseShenandoahGC -XX:MarkSweepDeadRatio=0 -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:+IgnoreUnrecognizedVMOptions jdk.jfr.event.gc.objectcount.TestObjectCountAfterGCEventWithShenandoah
> 
> Are all of these flags necessary to run this test? Can we pare any unnecessary options?

All of the collectors that test for the ObjectCountAfterGC event uses these flags. I thought it would be best to keep it consistent for the Shenandoah test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317633120
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317630478
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317545276
PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317555401

From duke at openjdk.org  Wed Sep  3 15:54:25 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 15:54:25 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
Message-ID: <UOoyzVf5nROGoxZimRWNdikzha7DV4T-BCObVg3KBhc=.30fdb10d-ad36-420e-8b1f-0b9e8c18bfb5@github.com>

On Wed, 3 Sep 2025 02:58:42 GMT, pf0n <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 179:
>> 
>>> 177:   // Use object counting closure if ObjectCount or ObjectCountAfterGC event is enabled.
>>> 178:   const bool object_count_enabled = ObjectCountEventSender::should_send_event();
>>> 179:   if (object_count_enabled && !ShenandoahHeap::heap()->mode()->is_generational()) {
>> 
>> Can the generational mode support this? It can also perform a _global_ collection.
>
> It could be possible to extend the object counting closure for GenShen. I would have to look more deep into where the closure can be used.

GenShen shares the same marking closure as Shenandoah, but it is templatized differently. At surface level, we would just have to replace the marking closure used for the global collection with the object counting closure, but there might be other work to be done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317645883

From pchilanomate at openjdk.org  Wed Sep  3 15:59:51 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Sep 2025 15:59:51 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v4]
In-Reply-To: <xT5AoTfA0VvTmGZqTuVoZtrBJf4NifwAXF1hR_Jbh5w=.ecffaf10-4c52-4d76-ac34-13a21b2567d1@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <xT5AoTfA0VvTmGZqTuVoZtrBJf4NifwAXF1hR_Jbh5w=.ecffaf10-4c52-4d76-ac34-13a21b2567d1@github.com>
Message-ID: <sUr2X1WTJd8zxpUNKmck7Kn4SSJ-fyHYyFCa8hngbBc=.492cebbf-02e3-40ef-866a-b5aa1951c985@github.com>

On Fri, 29 Aug 2025 19:11:04 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates
>>   `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();`
>> to find if method exit normally or by exception.
>> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See
>> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)`
>> where post_method_exit_inner is called directly.
>> 
>> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. 
>> 
>> 
>> The fix was a part of
>> https://github.com/openjdk/jdk/pull/26713
>> for
>> https://bugs.openjdk.org/browse/JDK-8365192
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: Patricio Chilano Mateo <patricio.chilano.mateo at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp
>    
>    Co-authored-by: Patricio Chilano Mateo <patricio.chilano.mateo at oracle.com>

Marked as reviewed by pchilanomate (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26886#pullrequestreview-3181311632

From duke at openjdk.org  Wed Sep  3 16:49:03 2025
From: duke at openjdk.org (pf0n)
Date: Wed, 3 Sep 2025 16:49:03 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <LLDq2GcPWoFwS-GU_fCeoKJX5RP0r5aaw2ux6NgfmB4=.6ebf7efc-67a3-4764-befe-f17a7a0d2b29@github.com>

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

pf0n has updated the pull request incrementally with two additional commits since the last revision:

 - Using JFR_ONLY
 - Changed comment, included another guard

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26977/files
  - new: https://git.openjdk.org/jdk/pull/26977/files/9552c62b..6a3c6318

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

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

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

From kevinw at openjdk.org  Wed Sep  3 18:48:43 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 3 Sep 2025 18:48:43 GMT
Subject: RFR: 8366695: Test
 sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out
In-Reply-To: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
References: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
Message-ID: <WZNubFmbrwX06HPP1nwjkFE_KHra4ZHnoL1Utx97X7Q=.8f2f6a95-fcf4-4318-81fe-47eaeab6911c@github.com>

On Wed, 3 Sep 2025 03:18:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java create 10 java processes, and maybe this cause this test timed out when run this test with other jtreg tests concurrently. Though the run time statistics shows that it do not run timed out, but it did on the brink of timed out.
> 
> After JDK-8260555 change the default jtreg timeout factor from 4 to 1, I think it's necessary to change the timeout value in sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java from 120(default value) to 240, to avoid this test run timed out intermittently.

OK.  Hopefully the timeout update keeps it reliable.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27064#pullrequestreview-3181990620

From iklam at openjdk.org  Wed Sep  3 19:36:51 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 3 Sep 2025 19:36:51 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v6]
In-Reply-To: <MlrcnDPAA4pFQwF7vykRD4VsFQVOal21G70Jvp5J39g=.37029289-8725-4b68-90bb-e46219e78e8d@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <MlrcnDPAA4pFQwF7vykRD4VsFQVOal21G70Jvp5J39g=.37029289-8725-4b68-90bb-e46219e78e8d@github.com>
Message-ID: <yh7pxOs3GSyr-edlYAHQVQumA6-fmERNRZ818J1NNck=.7a9e7600-1680-4c39-a381-7dec8731f784@github.com>

On Fri, 22 Aug 2025 15:06:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25
>
> Chen Liang 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 11 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
>  - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Variable name improvements
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Move other tier 4,5, etc tests to not use ClassReader
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Use classfile api instead of javac setting version
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/e0d5ae0b...a659f538

I looked at the diff with whitespace off and looked at all change. They seem reasonable to me. The bytecode changes seems to be 1-1 matching with the old code. I just have a few style nits.

Since the changes are subtle, I think before integration, you should do a final run up to tier 6 just to be safe.

test/hotspot/jtreg/compiler/jvmci/common/CTVMUtilities.java line 80:

> 78:             throw new Error("TEST BUG: cannot read " + binaryName, e);
> 79:         }
> 80:         ClassModel classModel = ClassFile.of().parse(fileBytes);

Can you put these in a separate function, like `ClassModel getClassModel(Class<?> class)`?

test/hotspot/jtreg/compiler/jvmci/common/CTVMUtilities.java line 93:

> 91:         for (var methodModel : classModel.methods()) {
> 92:             if (methodModel.methodName().equalsString(methodName)
> 93:                     && methodModel.methodType().isMethodType(methodType)) {

For readability, I think we should put the above in a separate function, and then:


var methodModel = findMethodInClass(classModel, m);


Then we can potentially use findMethodInClass() in other test cases when we have a need to do so.

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java line 64:

> 62:             var foundStackMapTable = method.code().flatMap(code -> code.findAttribute(Attributes.stackMapTable()));
> 63:             if (foundStackMapTable.isPresent()) {
> 64:                 count += foundStackMapTable.get().entries().size();

The old logging should be preserved:

log(" method " + name + " - " + methodFrames + " frames");

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 104:

> 102:                 public void atEnd(ClassBuilder builder) {
> 103:                     // Re-add dummy fields
> 104:                     dummyFields.forEach(builder);

Comment: `// Re-add dummy fields at the end of the class`

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-3182050159
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2319959194
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2319956360
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2319921409
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2319969688

From ysr at openjdk.org  Thu Sep  4 00:15:49 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Sep 2025 00:15:49 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
Message-ID: <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com>

On Wed, 3 Sep 2025 01:31:24 GMT, pf0n <duke at openjdk.org> wrote:

>> src/hotspot/share/memory/heapInspection.hpp line 33:
>> 
>>> 31: #include "oops/objArrayOop.hpp"
>>> 32: #include "oops/oop.hpp"
>>> 33: #include "runtime/mutex.hpp"
>> 
>> Does this need to be in the header?
>
> I had an error in GHA during my early implementation, so I included that header. I'll remove and test to see if it is needed or not.

I believe you need it for this: https://github.com/pf0n/jdk/blob/f43e334bf76f878ec688cbd58a5ab1cb10deb0f9/src/hotspot/share/memory/heapInspection.hpp#L218

It probably happens to work at other places because of preceding includes that happen to satisfy this. Explicitly including it here makes sense for that reason. Not sure why it just started showing up, but likely a new use that didn't otherwise satisfy this include.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320510893

From duke at openjdk.org  Thu Sep  4 00:27:49 2025
From: duke at openjdk.org (pf0n)
Date: Thu, 4 Sep 2025 00:27:49 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
 <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com>
Message-ID: <zpYqUbIOOXyW5NYLgU28BOypxufdRr1crkOYLfJ7kUk=.0dad4d5e-29bc-4114-9652-0d655e45e9a5@github.com>

On Thu, 4 Sep 2025 00:12:48 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> I had an error in GHA during my early implementation, so I included that header. I'll remove and test to see if it is needed or not.
>
> I believe you need it for this: https://github.com/pf0n/jdk/blob/f43e334bf76f878ec688cbd58a5ab1cb10deb0f9/src/hotspot/share/memory/heapInspection.hpp#L218
> 
> It probably happens to work at other places because of preceding includes that happen to satisfy this. Explicitly including it here makes sense for that reason. Not sure why it just started showing up, but likely a new use that didn't otherwise satisfy this include.

I forgot to circle back on this, but there are files that I created that includes `heapInspection.hpp`. I get an incomplete type for the Mutex class if I don't include `mutex.hpp`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320521485

From dlong at openjdk.org  Thu Sep  4 00:31:42 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 4 Sep 2025 00:31:42 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <j17HsQMH4wjiC9yAOssV1Ivx6dOMyUw_dgT-Q0KlV-c=.b7523e4d-515f-4384-adb3-cc3c9763db5c@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <j17HsQMH4wjiC9yAOssV1Ivx6dOMyUw_dgT-Q0KlV-c=.b7523e4d-515f-4384-adb3-cc3c9763db5c@github.com>
Message-ID: <pUL45XVf0NV3n93568ueZXcoW_l4UquTL5czT5ZXxjA=.8de29494-8151-4ac5-9c9b-4a18a163d5ed@github.com>

On Wed, 3 Sep 2025 07:12:20 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - revert whitespace change
>>  - undo debug changes
>>  - cleanup
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java line 372:
> 
>> 370:         // DEBUG_ONLY(verifyDeoptriginalPc(senderNm, raw_unextendedSp));
>> 371:       }
>> 372:     }
> 
> `<arch>Frame.java adjustUnextendedSP()` do not seem to do anything? Perhaps these could be cleaned up as well?

Yes, it's tempting to want to clean these up, but I noticed that SA code really tries to mirror the C++ code, so I'm inclined to leave it.  Is there a Serviceability expert that would like to see this code cleaned up further?  @plummercj , what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2320526360

From dholmes at openjdk.org  Thu Sep  4 00:43:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 00:43:41 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass* [v3]
In-Reply-To: <vDJPmg7qEVe9BtbcgtJ_CGeGhGEPC9wTz5WLebpGaw0=.20981d85-5e70-43a7-a8b9-4dd7b4b5940c@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <vDJPmg7qEVe9BtbcgtJ_CGeGhGEPC9wTz5WLebpGaw0=.20981d85-5e70-43a7-a8b9-4dd7b4b5940c@github.com>
Message-ID: <38qyt72puP7IM-UHRTFW8PF17T1V-w3gHMRDkkNF1NY=.40073263-bf18-4726-9101-9710868e20d7@github.com>

On Tue, 2 Sep 2025 21:08:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code
>> 
>> 
>> InstanceKlass* ik;
>> InstanceKlass* s;
>> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 
>> s = ik->java_super(); // after JDK-8366024 
>> 
>> 
>> to
>> 
>> 
>> s = k->super();
>> 
>> 
>> So you no longer need to do casting or need to understand what `java_super()` is.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora and @coleep comments

Updates look good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27037#pullrequestreview-3182970156

From dholmes at openjdk.org  Thu Sep  4 00:57:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 00:57:48 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v5]
In-Reply-To: <FX255eFGF9j00L-t0STNPnYPnFz69Ca6BDxNZsFQ6e4=.9358bf6e-2bff-43f6-ba4d-1029eafe76c6@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <FX255eFGF9j00L-t0STNPnYPnFz69Ca6BDxNZsFQ6e4=.9358bf6e-2bff-43f6-ba4d-1029eafe76c6@github.com>
Message-ID: <Y4MaeHZv1T3HxDldB8cNvLBHotntbnszu8-30C-s95Y=.260cd3cc-29ac-4469-ac6c-61ef0a0e5f52@github.com>

On Tue, 2 Sep 2025 21:45:03 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds linking a class before the `copy_bytecodes` method is called.
>> The PR also adds a regression test.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - The regression test passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to macros HAS_PENDING_EXCEPTION, CLEAR_PENDING_EXCEPTION

Generally looks good. There are a few minor nits/typos.

I'm not sure about the test, in particular the attempt to calculate `MIN_LINK_TIME_MS`. It is very hard to see/know that you will actually induce the desired race. But as the test doesn't actually have any explicit failure conditions, it at least won't generate false reports.

Thanks

src/hotspot/share/prims/jvmtiEnv.cpp line 454:

> 452:     if (ik->get_cached_class_file_bytes() == nullptr) {
> 453:       // Link the class to avoid races with the rewriter. This will call the verifier also
> 454:       // on the class. Linking is done already below in VM_RedefineClasses below, but we need

Suggestion:

      // on the class. Linking is also done in VM_RedefineClasses below, but we need

There are two "below"s

test/jdk/java/lang/instrument/RetransformBigClassTest.java line 44:

> 42:  * in another thread. The test uses Class.forName("BigClass", false, classLoader)
> 43:  * which does not link the class. When the class is used, the linking process starts.
> 44:  * In another thread retransforming of the class is happening,

Suggestion:

 * In another thread retransforming of the class is happening.

test/jdk/java/lang/instrument/RetransformBigClassTest.java line 45:

> 43:  * which does not link the class. When the class is used, the linking process starts.
> 44:  * In another thread retransforming of the class is happening,
> 45:  * We generate a class with big methods. A number of methods and thier size are

Suggestion:

 * We generate a class with big methods. A number of methods and their size are

test/jdk/java/lang/instrument/RetransformBigClassTest.java line 46:

> 44:  * In another thread retransforming of the class is happening,
> 45:  * We generate a class with big methods. A number of methods and thier size are
> 46:  * chosen to make the linking and retransforming processes running concurrently.

Suggestion:

 * chosen to make the linking and retransforming processes run concurrently.

test/jdk/java/lang/instrument/RetransformBigClassTest.java line 54:

> 52:     private static final Object LOCK = new Object();
> 53:     private static final int COUNTER_INC_COUNT            = 2000; // A number of 'c+=1;' statements in methods of a class.
> 54:     private static final int MIN_LINK_TIME_MS             = 60;   // This time is chosen to be big enough the linking and retransforming processes are running in parallel.

Suggestion:

    private static final int MIN_LINK_TIME_MS             = 60;   // Large enough so linking and retransforming run in parallel.

test/jdk/java/lang/instrument/RetransformBigClassTest.java line 108:

> 106:     }
> 107: 
> 108:     // We calculate a number of methods the linking time to exceed MIN_LINK_TIME_MS.

I can't quite parse this sentence.

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

PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3182975103
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320540581
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320542950
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320543345
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320543595
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320544630
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320546835

From syan at openjdk.org  Thu Sep  4 01:31:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 01:31:59 GMT
Subject: RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out
 after 60 second [v3]
In-Reply-To: <miskMVDUEeMwirE4dN5H4z2H80qIZD0EjokSXMlFe3g=.9045e8e0-a1ac-481e-b759-ab10bb64425c@github.com>
References: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
 <miskMVDUEeMwirE4dN5H4z2H80qIZD0EjokSXMlFe3g=.9045e8e0-a1ac-481e-b759-ab10bb64425c@github.com>
Message-ID: <lGVuwyhNrP7GthSj5ViwUCZ1yj5YqsLV_709I3DGqJc=.0dbd284f-cd5c-4514-a0a8-3cc48a20fdaf@github.com>

On Wed, 3 Sep 2025 01:49:04 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . 
>> 
>> This PR add '-Xmx64' to make debugee JVM to finish the java heap allocation quickly.
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan 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 branch 'openjdk:master' into jbs8366694
>  - Use addDebuggeeOptions(-Xmx64) to make test run quickly, instead of add timeout value
>  - 8366694: Test JdbStopInNotificationThreadTest.java timed out after 60 second

Thanks all for the suggestions and reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/27055#issuecomment-3251364122

From syan at openjdk.org  Thu Sep  4 01:31:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 01:31:59 GMT
Subject: Integrated: 8366694: Test JdbStopInNotificationThreadTest.java timed
 out after 60 second
In-Reply-To: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
References: <YERNCEd9BmL-e0rwl9kKWcLkJ08Fkp2PLZ2-zMWx1k4=.cfc3208b-ba27-4d27-a35b-964dcd120f76@github.com>
Message-ID: <jEymh8oHExajTekpzUXSRkYihBAeS6AgO6oyPevvfbI=.595e82ac-78f6-4f06-9a9c-041a85ae0932@github.com>

On Tue, 2 Sep 2025 15:10:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . 
> 
> This PR add '-Xmx64' to make debugee JVM to finish the java heap allocation quickly.
> 
> Change has been verified locally, no risk.

This pull request has now been integrated.

Changeset: ed62bda2
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed62bda2e0c51a67baae1fc28e41c9cd878db5f4
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8366694: Test JdbStopInNotificationThreadTest.java timed out after 60 second

Reviewed-by: cjplummer, ayang, lmesnik

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

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

From syan at openjdk.org  Thu Sep  4 01:39:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 01:39:53 GMT
Subject: RFR: 8366695: Test
 sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out
In-Reply-To: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
References: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
Message-ID: <1mCcTgee6lYkNl4zw1Yc0FHVVQiEIKyWe9HopyT9WZU=.02cf8f28-7045-456f-a1ba-8b907bd096cf@github.com>

On Wed, 3 Sep 2025 03:18:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java create 10 java processes, and maybe this cause this test timed out when run this test with other jtreg tests concurrently. Though the run time statistics shows that it do not run timed out, but it did on the brink of timed out.
> 
> After JDK-8260555 change the default jtreg timeout factor from 4 to 1, I think it's necessary to change the timeout value in sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java from 120(default value) to 240, to avoid this test run timed out intermittently.

GHA report test jdk/jshell/ToolLocalSimpleTest.java fails on windows-x64, this fails has been recorded by [JDK-8366582](https://bugs.openjdk.org/browse/JDK-8366582), I think it's unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27064#issuecomment-3251377300

From syan at openjdk.org  Thu Sep  4 01:39:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 01:39:53 GMT
Subject: RFR: 8366695: Test
 sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out
In-Reply-To: <WZNubFmbrwX06HPP1nwjkFE_KHra4ZHnoL1Utx97X7Q=.8f2f6a95-fcf4-4318-81fe-47eaeab6911c@github.com>
References: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
 <WZNubFmbrwX06HPP1nwjkFE_KHra4ZHnoL1Utx97X7Q=.8f2f6a95-fcf4-4318-81fe-47eaeab6911c@github.com>
Message-ID: <HOb88QqVY9RX8Fv83TsE-vyLtYreBiLhTBcc-Mt_5E4=.2003f104-3661-460b-bac6-34360bedfc1d@github.com>

On Wed, 3 Sep 2025 18:46:23 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hi all,
>> 
>> Test sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java create 10 java processes, and maybe this cause this test timed out when run this test with other jtreg tests concurrently. Though the run time statistics shows that it do not run timed out, but it did on the brink of timed out.
>> 
>> After JDK-8260555 change the default jtreg timeout factor from 4 to 1, I think it's necessary to change the timeout value in sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java from 120(default value) to 240, to avoid this test run timed out intermittently.
>
> OK.  Hopefully the timeout update keeps it reliable.

Thanks for the reviews @kevinjwalls @lmesnik

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

PR Comment: https://git.openjdk.org/jdk/pull/27064#issuecomment-3251379490

From syan at openjdk.org  Thu Sep  4 01:39:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 01:39:54 GMT
Subject: Integrated: 8366695: Test
 sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out
In-Reply-To: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
References: <oCmnvcT2GDbkVrhumJMPOnqSiCodMl1LJUqYTRxRNmE=.6f142505-b027-4ea0-a8cd-5361e79a8c7d@github.com>
Message-ID: <I-U2Z0_6DrDsA_6XpOxSph-xqaWoV2cZqYIAUIvASTQ=.654c2a7a-78bb-4f0b-8b5d-4eea1a8c881f@github.com>

On Wed, 3 Sep 2025 03:18:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java create 10 java processes, and maybe this cause this test timed out when run this test with other jtreg tests concurrently. Though the run time statistics shows that it do not run timed out, but it did on the brink of timed out.
> 
> After JDK-8260555 change the default jtreg timeout factor from 4 to 1, I think it's necessary to change the timeout value in sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java from 120(default value) to 240, to avoid this test run timed out intermittently.

This pull request has now been integrated.

Changeset: 11743b1e
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11743b1ed3d681ce17c2342616c4040c4b539b31
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8366695: Test sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out

Reviewed-by: lmesnik, kevinw

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

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

From asmehra at openjdk.org  Thu Sep  4 01:50:50 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 4 Sep 2025 01:50:50 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3]
In-Reply-To: <wFkxQPaM8Z1B66tQvPvi-DDWbWODU5gwHeYE7OMSsFM=.5853ff2c-2214-44d3-b679-3d9f9fdf84a2@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
 <wFkxQPaM8Z1B66tQvPvi-DDWbWODU5gwHeYE7OMSsFM=.5853ff2c-2214-44d3-b679-3d9f9fdf84a2@github.com>
Message-ID: <RWGW6Whjd6vQ658Dln1bQwAR6UAnFT_bptK-ogHyFns=.6fd58d8e-79cb-4f27-8b42-1de75c07e40c@github.com>

On Sat, 30 Aug 2025 18:17:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
>> 
>> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker.
>> 
>> All changes are mechanical text replacement. Headers are resorted alphabetically.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unnecessary includes

src/hotspot/os/posix/vmError_posix.cpp line 27:

> 25: 
> 26: #include "cds/cdsConfig.hpp"
> 27: #include "cds/aotMetaspace.hpp"

There are few places, like this, where the header files are no longer in sorted order. Can you please update them.

src/hotspot/os/windows/vmError_windows.cpp line 26:

> 24: 
> 25: #include "cds/cdsConfig.hpp"
> 26: #include "cds/aotMetaspace.hpp"

header files are not sorted

src/hotspot/share/prims/jvm.cpp line 3507:

> 3505:   Handle file_handle(THREAD, JNIHandles::resolve_non_null(listFileName));
> 3506:   char* file_name  = java_lang_String::as_utf8_string(file_handle());
> 3507:   AOTMetaspace::dump_loaded_classes(file_name, THREAD);

Shouldn't this file include `aotMetaspace.hpp` directly?

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 26:

> 24: 
> 25: #include "cds/cdsConfig.hpp"
> 26: #include "cds/aotMetaspace.hpp"

headers are not sorted

src/hotspot/share/prims/whitebox.cpp line 30:

> 28: #include "cds/filemap.hpp"
> 29: #include "cds/heapShared.hpp"
> 30: #include "cds/aotMetaspace.hpp"

header files are not sorted

src/hotspot/share/runtime/java.cpp line 451:

> 449: 
> 450:   if (CDSConfig::is_dumping_preimage_static_archive()) {
> 451:     AOTMetaspace::preload_and_dump(thread);

Shouldn't this file include `aotMetaspace.hpp` directly?

src/hotspot/share/runtime/threads.cpp line 31:

> 29: #include "cds/cdsConfig.hpp"
> 30: #include "cds/heapShared.hpp"
> 31: #include "cds/aotMetaspace.hpp"

header files are not sorted

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320608881
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320608974
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609474
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609545
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609580
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609638
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609704

From ysr at openjdk.org  Thu Sep  4 01:58:47 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Sep 2025 01:58:47 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <zpYqUbIOOXyW5NYLgU28BOypxufdRr1crkOYLfJ7kUk=.0dad4d5e-29bc-4114-9652-0d655e45e9a5@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
 <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com>
 <zpYqUbIOOXyW5NYLgU28BOypxufdRr1crkOYLfJ7kUk=.0dad4d5e-29bc-4114-9652-0d655e45e9a5@github.com>
Message-ID: <kvyA4Km6GcTbvLGMO8WwIvlFZvHv_wkpxzAhJ3jwBQs=.617fc48a-077d-4065-b151-c6d21e7f2c22@github.com>

On Thu, 4 Sep 2025 00:24:37 GMT, pf0n <duke at openjdk.org> wrote:

>> I believe you need it for this: https://github.com/pf0n/jdk/blob/f43e334bf76f878ec688cbd58a5ab1cb10deb0f9/src/hotspot/share/memory/heapInspection.hpp#L218
>> 
>> It probably happens to work at other places because of preceding includes that happen to satisfy this. Explicitly including it here makes sense for that reason. Not sure why it just started showing up, but likely a new use that didn't otherwise satisfy this include.
>
> I forgot to circle back on this, but there are files that I created that includes `heapInspection.hpp`. I get an incomplete type for the Mutex class if I don't include `mutex.hpp`.

Makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320618033

From ysr at openjdk.org  Thu Sep  4 02:07:52 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Sep 2025 02:07:52 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v2]
In-Reply-To: <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
 <OPZ8vhzy70VNYJu-pVgX-3Te33auMyDb3330R_s3F0I=.1a2a1742-fc26-4735-9847-18947f48c7bf@github.com>
 <espHeZfIfmymTBYI7AuHKpolClx2KVpFND7dFQMrqko=.e465c236-8d2c-42ec-8cb8-f1a49f258274@github.com>
Message-ID: <SudZ1va_xJeFpa7ujHhojOq-zVTLgFdfVF0YG2M4pIo=.4b7655df-de9a-4726-9c06-42a3801374ff@github.com>

On Wed, 3 Sep 2025 01:41:15 GMT, pf0n <duke at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithShenandoah.java line 11:
>> 
>>> 9:  *           & vm.opt.ExplicitGCInvokesConcurrent != true
>>> 10:  * @library /test/lib /test/jdk
>>> 11:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -XX:+UseShenandoahGC -XX:MarkSweepDeadRatio=0 -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:+IgnoreUnrecognizedVMOptions jdk.jfr.event.gc.objectcount.TestObjectCountAfterGCEventWithShenandoah
>> 
>> Are all of these flags necessary to run this test? Can we pare any unnecessary options?
>
> All of the collectors that test for the ObjectCountAfterGC event uses these flags. I thought it would be best to keep it consistent for the Shenandoah test.

Best practice is to remove flags that are no-ops, otherwise we accrue junk here.

I'd urge removal of such cruft, in particular: MarkSweepDeadRatio, UseCompressedOops & UseCompressedClassPointers (which you may have added for debugging ease), and IgnoreUnrecognizedVMOptions (which should, I think, not be there in any tests unless there is an explicitly stated reason to include it). I am not sure we even need UseFastUnorderedTimeStamps either since the test does not, to my knowledge, examine the order of timestamped events in the JFR recording. If further constraint checking is added to the tests that requires this, it should be added back at that time.

For the other collectors, we can consider a separate ticket to clean any unnecessary flags up (I suspect only MarkSweepDeadRatio may be needed for the cases where one is looking for a collection to necessarily move objects-- which I don't think these tests test for -- so even that flag appears unnecessary at least for these tests.)

I vote for unburdening the flag load for the new Shenandoah test at least, as suggested by William.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320627227

From liach at openjdk.org  Thu Sep  4 02:19:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Sep 2025 02:19:47 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v2]
In-Reply-To: <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
 <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
Message-ID: <6zhlR-iAP-D-47ELJS2xd_eHm1De2raHknG1h9JibgY=.d6fc1d4e-8e54-4560-a9f4-70102fc432d3@github.com>

On Sat, 30 Aug 2025 17:34:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
>> 
>> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
>> - tests if an object is inside the AOT cache's metaspace region.
>> 
>> Also various forms of  "shared metaspace" are updated to "aot metaspace"
>> 
>> Please start your review with allocations.hpp
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017

This rename is absolutely clarifying. Did not review the technical aspects of hotspot.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27016#pullrequestreview-3183181361

From iklam at openjdk.org  Thu Sep  4 02:33:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 02:33:52 GMT
Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass* [v3]
In-Reply-To: <Qn6AlA3zHuAwEvCmE2GBQMfE9LkvSF5FhvZZs3qDtcU=.fd45e7d9-52c3-4840-ab2e-563b6a15ca72@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
 <vDJPmg7qEVe9BtbcgtJ_CGeGhGEPC9wTz5WLebpGaw0=.20981d85-5e70-43a7-a8b9-4dd7b4b5940c@github.com>
 <Qn6AlA3zHuAwEvCmE2GBQMfE9LkvSF5FhvZZs3qDtcU=.fd45e7d9-52c3-4840-ab2e-563b6a15ca72@github.com>
Message-ID: <hrDFHgjL_4epnCUD_5Jv6hkHfRqrxX_LhhSVL8yxUeU=.d7651665-d538-407c-bcd5-43ab12dcf2ad@github.com>

On Wed, 3 Sep 2025 11:38:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dholmes-ora and @coleep comments
>
> Looks good.  This will help with InstanceKlass casting.

Thanks @coleenp @dholmes-ora for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27037#issuecomment-3251513937

From iklam at openjdk.org  Thu Sep  4 02:33:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 02:33:52 GMT
Subject: Integrated: 8366584: Add an InstanceKlass::super() method that returns
 InstanceKlass*
In-Reply-To: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
References: <fjS-CBL3BlEDCtLVCJZpMgzNfzIz4T6jty8n5uyvcJ8=.5e95c807-1ca7-4631-ac9f-99f375fbd3eb@github.com>
Message-ID: <xvof7TZcf7q194AAMngrISZWgkFATqxfAesCZepbgVc=.0c33e455-290c-45ab-8605-05c0a7a48232@github.com>

On Tue, 2 Sep 2025 01:31:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code
> 
> 
> InstanceKlass* ik;
> InstanceKlass* s;
> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 
> s = ik->java_super(); // after JDK-8366024 
> 
> 
> to
> 
> 
> s = k->super();
> 
> 
> So you no longer need to do casting or need to understand what `java_super()` is.

This pull request has now been integrated.

Changeset: f4d73d2a
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4d73d2a3dbeccfd04d49c0cfd690086edd0544f
Stats:     93 lines in 28 files changed: 9 ins; 3 del; 81 mod

8366584: Add an InstanceKlass::super() method that returns InstanceKlass*

Reviewed-by: dholmes, coleenp

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

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

From dholmes at openjdk.org  Thu Sep  4 02:35:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 02:35:49 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Looks good. Great cleanup! A couple of nits/suggestions.

Thanks

src/hotspot/share/c1/c1_LIRGenerator.cpp line 638:

> 636:   LIR_Opr hdr = lock;
> 637:   lock = new_hdr;
> 638:   CodeStub* slow_path = new MonitorExitStub(lock, true, monitor_no);

It seems all creators for `MonitorExitStub` now pass `true` so that parameter can be removed.

src/hotspot/share/runtime/basicLock.hpp line 40:

> 38:   // Used as a cache of the ObjectMonitor* used when locking. Must either
> 39:   // be nullptr or the ObjectMonitor* used when locking.
> 40:   volatile uintptr_t _metadata;

So this could now be a properly typed and named field. Future RFE.

src/hotspot/share/runtime/basicLock.hpp line 53:

> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
> 52: 
> 53:   // For lightweight locking

If the following are for lightweight locking then what are the two previous for?

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

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3179255959
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317998409
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320634417
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320643671

From dholmes at openjdk.org  Thu Sep  4 02:35:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 02:35:51 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
Message-ID: <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>

On Tue, 2 Sep 2025 20:15:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/runtime/basicLock.hpp line 51:
> 
>> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
>> 50: 
>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
> 
> Also delete line 51 ?

Still appears used in LIRAssembler. But the assert in which it is used doesn't really make sense as it just checks the offset == 0.

> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769:
> 
>> 767: 
>> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated
>> 769: // ObjectMonitor* when lightweight locking is used. It is used from contexts
> 
> I guess you don't need the phrase "when lightweight locking is used".

Even calling it "lightweight locking" is no longer needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320640694
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320651595

From iklam at openjdk.org  Thu Sep  4 03:06:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 03:06:29 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v3]
In-Reply-To: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
Message-ID: <Cgs9TB9HfmlRsr5bOPZ2svCfqnOAuamjnID_2LNLAwE=.95857842-902f-4260-9fd5-958be39c7c42@github.com>

> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
> 
> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
> - tests if an object is inside the AOT cache's metaspace region.
> 
> Also various forms of  "shared metaspace" are updated to "aot metaspace"
> 
> Please start your review with allocations.hpp

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared()
 - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache
 - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017
 - 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache()

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

Changes: https://git.openjdk.org/jdk/pull/27016/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27016&range=02
  Stats: 204 lines in 55 files changed: 3 ins; 0 del; 201 mod
  Patch: https://git.openjdk.org/jdk/pull/27016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27016/head:pull/27016

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

From iklam at openjdk.org  Thu Sep  4 03:06:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 03:06:29 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v2]
In-Reply-To: <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
 <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
Message-ID: <oo9UNVtn_faT6v-QFXEuQlXNfaugCzNIv6vyj_QKjV0=.31b24b97-b567-4ee3-9bef-2edbee85c106@github.com>

On Sat, 30 Aug 2025 17:34:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
>> 
>> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
>> - tests if an object is inside the AOT cache's metaspace region.
>> 
>> Also various forms of  "shared metaspace" are updated to "aot metaspace"
>> 
>> Please start your review with allocations.hpp
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017

I've merged with the mainline to resolve conflicts.

I also made one extra fix: `ConstantPool::is_shared()` was shadowing `MetaspaceObj::is_shared()`, so I renamed it to `in_aot_cache()`, so that it will now shadow `MetaspaceObj::in_aot_cache()`. See [17f8c0b](https://github.com/openjdk/jdk/pull/27016/commits/17f8c0bfe302504cd027435fa92cdc58f3362f7c)

@vnkozlov @liach could you re-review?

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

PR Comment: https://git.openjdk.org/jdk/pull/27016#issuecomment-3251598867

From liach at openjdk.org  Thu Sep  4 03:30:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Sep 2025 03:30:43 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v3]
In-Reply-To: <Cgs9TB9HfmlRsr5bOPZ2svCfqnOAuamjnID_2LNLAwE=.95857842-902f-4260-9fd5-958be39c7c42@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
 <Cgs9TB9HfmlRsr5bOPZ2svCfqnOAuamjnID_2LNLAwE=.95857842-902f-4260-9fd5-958be39c7c42@github.com>
Message-ID: <VjH-b_Gg36zAfud_hah5V9iZ_1HVbAvlqava615p3wA=.539723bc-502b-475a-bc13-8d45a5ae28bd@github.com>

On Thu, 4 Sep 2025 03:06:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
>> 
>> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
>> - tests if an object is inside the AOT cache's metaspace region.
>> 
>> Also various forms of  "shared metaspace" are updated to "aot metaspace"
>> 
>> Please start your review with allocations.hpp
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared()
>  - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache
>  - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017
>  - 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache()

The subsequent fix looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27016#pullrequestreview-3183291587

From iklam at openjdk.org  Thu Sep  4 04:50:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 04:50:47 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v2]
In-Reply-To: <Y11cOL6Q_9AKFNe5ylu_GtGQ9b5bQhOCGh7CTxJDXK8=.5b6aa27a-96f8-4f41-b345-2a2a91b428a0@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
 <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
 <Y11cOL6Q_9AKFNe5ylu_GtGQ9b5bQhOCGh7CTxJDXK8=.5b6aa27a-96f8-4f41-b345-2a2a91b428a0@github.com>
Message-ID: <MsfgJyrA3sYQtHXMM9MRWraV-ThjVJklTN1tyn9K9ck=.a24c137f-0a66-4408-9ce2-745991cc7eac@github.com>

On Sat, 30 Aug 2025 19:45:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017
>
> Update is good.

Thanks @vnkozlov @liach for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27016#issuecomment-3251834527

From iklam at openjdk.org  Thu Sep  4 04:50:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 04:50:48 GMT
Subject: Integrated: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache()
In-Reply-To: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
Message-ID: <Tufib8MgwfHBPiF2hSE0OvTRl_KoiDoDdUjROr-BVeg=.dceec4b4-e148-4bb6-8806-b92e6effcbc2@github.com>

On Sat, 30 Aug 2025 02:13:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
> 
> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
> - tests if an object is inside the AOT cache's metaspace region.
> 
> Also various forms of  "shared metaspace" are updated to "aot metaspace"
> 
> Please start your review with allocations.hpp

This pull request has now been integrated.

Changeset: 90a2db1e
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90a2db1ecbc3ea25a8e9f15b34a3d8f3941b60d0
Stats:     204 lines in 55 files changed: 3 ins; 0 del; 201 mod

8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache()

Reviewed-by: liach, kvn

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

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

From iklam at openjdk.org  Thu Sep  4 05:38:20 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 05:38:20 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v4]
In-Reply-To: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
Message-ID: <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com>

> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
> 
> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker.
> 
> All changes are mechanical text replacement. Headers are resorted alphabetically.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Fixed include order
 - Merge branch 'master' into 8366475-rename-metaspace-shared-to-aot-metaspace
 - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace
 - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared()
 - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache
 - removed unnecessary includes
 - Redo changes in comments and tests
 - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace
 - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017
 - Rename MetaspaceShared -> AOTMetaspace
 - ... and 1 more: https://git.openjdk.org/jdk/compare/90a2db1e...63073feb

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

Changes: https://git.openjdk.org/jdk/pull/27017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27017&range=03
  Stats: 367 lines in 60 files changed: 35 ins; 35 del; 297 mod
  Patch: https://git.openjdk.org/jdk/pull/27017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27017/head:pull/27017

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

From iklam at openjdk.org  Thu Sep  4 05:38:21 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 05:38:21 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3]
In-Reply-To: <RWGW6Whjd6vQ658Dln1bQwAR6UAnFT_bptK-ogHyFns=.6fd58d8e-79cb-4f27-8b42-1de75c07e40c@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
 <wFkxQPaM8Z1B66tQvPvi-DDWbWODU5gwHeYE7OMSsFM=.5853ff2c-2214-44d3-b679-3d9f9fdf84a2@github.com>
 <RWGW6Whjd6vQ658Dln1bQwAR6UAnFT_bptK-ogHyFns=.6fd58d8e-79cb-4f27-8b42-1de75c07e40c@github.com>
Message-ID: <OJ3FsO0iFdsFDKSP7JbTx5_qU862aE5dna6Os8IOBLc=.16b42928-a626-4a69-83c2-f3db28e00b05@github.com>

On Thu, 4 Sep 2025 01:47:23 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed unnecessary includes
>
> src/hotspot/os/posix/vmError_posix.cpp line 27:
> 
>> 25: 
>> 26: #include "cds/cdsConfig.hpp"
>> 27: #include "cds/aotMetaspace.hpp"
> 
> There are few places, like this, where the header files are no longer in sorted order. Can you please update them.

Fixed.

> src/hotspot/os/windows/vmError_windows.cpp line 26:
> 
>> 24: 
>> 25: #include "cds/cdsConfig.hpp"
>> 26: #include "cds/aotMetaspace.hpp"
> 
> header files are not sorted

Fixed.

> src/hotspot/share/prims/jvm.cpp line 3507:
> 
>> 3505:   Handle file_handle(THREAD, JNIHandles::resolve_non_null(listFileName));
>> 3506:   char* file_name  = java_lang_String::as_utf8_string(file_handle());
>> 3507:   AOTMetaspace::dump_loaded_classes(file_name, THREAD);
> 
> Shouldn't this file include `aotMetaspace.hpp` directly?

Fixed.

> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 26:
> 
>> 24: 
>> 25: #include "cds/cdsConfig.hpp"
>> 26: #include "cds/aotMetaspace.hpp"
> 
> headers are not sorted

Fixed.

> src/hotspot/share/prims/whitebox.cpp line 30:
> 
>> 28: #include "cds/filemap.hpp"
>> 29: #include "cds/heapShared.hpp"
>> 30: #include "cds/aotMetaspace.hpp"
> 
> header files are not sorted

Fixed.

> src/hotspot/share/runtime/java.cpp line 451:
> 
>> 449: 
>> 450:   if (CDSConfig::is_dumping_preimage_static_archive()) {
>> 451:     AOTMetaspace::preload_and_dump(thread);
> 
> Shouldn't this file include `aotMetaspace.hpp` directly?

Fixed.

> src/hotspot/share/runtime/threads.cpp line 31:
> 
>> 29: #include "cds/cdsConfig.hpp"
>> 30: #include "cds/heapShared.hpp"
>> 31: #include "cds/aotMetaspace.hpp"
> 
> header files are not sorted

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320880870
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320880937
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320880998
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320881088
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320881141
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320881190
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320881262

From dholmes at openjdk.org  Thu Sep  4 06:39:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 06:39:51 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v4]
In-Reply-To: <xT5AoTfA0VvTmGZqTuVoZtrBJf4NifwAXF1hR_Jbh5w=.ecffaf10-4c52-4d76-ac34-13a21b2567d1@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <xT5AoTfA0VvTmGZqTuVoZtrBJf4NifwAXF1hR_Jbh5w=.ecffaf10-4c52-4d76-ac34-13a21b2567d1@github.com>
Message-ID: <C_ktw0O6MO-8lsPXHc2cN5kYBPfOX8rMLEsX0Usq6Rw=.9cc586ff-2b21-43bd-8ea8-9c4cc8b66c75@github.com>

On Fri, 29 Aug 2025 19:11:04 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates
>>   `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();`
>> to find if method exit normally or by exception.
>> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See
>> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)`
>> where post_method_exit_inner is called directly.
>> 
>> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. 
>> 
>> 
>> The fix was a part of
>> https://github.com/openjdk/jdk/pull/26713
>> for
>> https://bugs.openjdk.org/browse/JDK-8365192
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: Patricio Chilano Mateo <patricio.chilano.mateo at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp
>    
>    Co-authored-by: Patricio Chilano Mateo <patricio.chilano.mateo at oracle.com>

Okay with me. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26886#pullrequestreview-3183671829

From fbredberg at openjdk.org  Thu Sep  4 09:32:44 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 09:32:44 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
Message-ID: <WMI9YeW1LQDQUrD4wsR54qWnveFCSqdXctjVN55isGg=.cc90e31e-3cb9-4d5c-b80f-6286b80db4b8@github.com>

On Tue, 2 Sep 2025 20:11:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 344:
> 
>> 342:   volatile_nonstatic_field(ObjectMonitor,      _entry_list,                                   ObjectWaiter*)                         \
>> 343:   volatile_nonstatic_field(ObjectMonitor,      _succ,                                         int64_t)                               \
>> 344:   volatile_nonstatic_field(ObjectMonitor,      _stack_locker,                                 BasicLock*)                            \
> 
> There are some jvmci tests that check that the java side of jvmci matches, ie:
> 
> make test TEST=compiler/jvmci

Tried that and got:
`TEST SUCCESS`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321428734

From fbredberg at openjdk.org  Thu Sep  4 09:48:45 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 09:48:45 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
 <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
Message-ID: <SIs0ZM-BB6p9kbd0vhXQLGK2nU04ADkz3QcckKFOexU=.322fd9a7-42cc-4a5a-80e0-d63d2b328c11@github.com>

On Thu, 4 Sep 2025 02:16:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/basicLock.hpp line 51:
>> 
>>> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
>>> 50: 
>>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
>> 
>> Also delete line 51 ?
>
> Still appears used in LIRAssembler. But the assert in which it is used doesn't really make sense as it just checks the offset == 0.

This is unfortunately still used by some of the platform files. Since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321466475

From fbredberg at openjdk.org  Thu Sep  4 10:00:45 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 10:00:45 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <0CMB0g0_Ru1hF5l2NA194kD1ouNwMXrB1667Uvl9mFQ=.b6834c47-be53-41bb-b726-2e282517d6bc@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <0CMB0g0_Ru1hF5l2NA194kD1ouNwMXrB1667Uvl9mFQ=.b6834c47-be53-41bb-b726-2e282517d6bc@github.com>
Message-ID: <Q9XERDwEJhJZOlDuj1ufQSUyXhdMw0-5HSTeRZ2cEeg=.b4087d4f-8554-4066-a2c0-102bd1ce9617@github.com>

On Wed, 3 Sep 2025 07:37:34 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/runtime/basicLock.hpp line 51:
> 
>> 49:   void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }
>> 50: 
>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
> 
> The `badDispHeaderDeopt` and `badDispHeaderOSR` constants should also be renamed.

Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

> src/hotspot/share/runtime/synchronizer.cpp line 634:
> 
>> 632: }
>> 633: 
>> 634: static intptr_t install_hash_code(Thread* current, oop obj) {
> 
> A future RFE could potentially simplify and unify this with `FastHashCode`

Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321495256
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321493463

From fbredberg at openjdk.org  Thu Sep  4 10:00:47 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 10:00:47 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
Message-ID: <CZRSry64icYZhI6xHfZ5_1713lUTvAGk7-NchbVftxI=.e6eb1a58-1fef-45f3-aad7-1d7de95b412c@github.com>

On Tue, 2 Sep 2025 20:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/runtime/javaThread.cpp line 2007:
> 
>> 2005: #ifdef SUPPORT_MONITOR_COUNT
>> 2006:   // Nothing to do. Just do some sanity check.
>> 2007:   assert(_held_monitor_count == 0, "counter should not be used");
> 
> In further cleanup, can we now remove _held_monitor_count next?

I think so, but I'm not sure. Anyhow I've added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

> src/hotspot/share/runtime/synchronizer.inline.hpp line 48:
> 
>> 46:   assert(current == Thread::current(), "must be");
>> 47: 
>> 48:     LightweightSynchronizer::enter(obj, lock, current);
> 
> In the further RFE, we should remove these dispatch functions too.

Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321483375
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321488805

From fbredberg at openjdk.org  Thu Sep  4 10:13:43 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 10:13:43 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
Message-ID: <_Ola7zEQaOGFemDMFTFkjmAouaLRxSJwarKbWnEKbDk=.4469db17-0021-450b-968e-b28267c626d4@github.com>

On Wed, 3 Sep 2025 07:16:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/c1/c1_LIRGenerator.cpp line 638:
> 
>> 636:   LIR_Opr hdr = lock;
>> 637:   lock = new_hdr;
>> 638:   CodeStub* slow_path = new MonitorExitStub(lock, true, monitor_no);
> 
> It seems all creators for `MonitorExitStub` now pass `true` so that parameter can be removed.

Good find! But this affects platform files, and since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

> src/hotspot/share/runtime/basicLock.hpp line 40:
> 
>> 38:   // Used as a cache of the ObjectMonitor* used when locking. Must either
>> 39:   // be nullptr or the ObjectMonitor* used when locking.
>> 40:   volatile uintptr_t _metadata;
> 
> So this could now be a properly typed and named field. Future RFE.

I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321521296
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321526089

From fbredberg at openjdk.org  Thu Sep  4 10:20:44 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 10:20:44 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
Message-ID: <-yO5kJRg9ghIK9ZHi8auSW22u__Ixsva-A4mvgadZic=.4f31754d-c0a9-4646-a3b7-40aade9678a4@github.com>

On Thu, 4 Sep 2025 02:18:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/share/runtime/basicLock.hpp line 53:
> 
>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
>> 52: 
>> 53:   // For lightweight locking
> 
> If the following are for lightweight locking then what are the two previous for?

For something old and soon forgotten. :)
After I had integrated some platforms I realized that this was no longer needed, but since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321540639

From coleenp at openjdk.org  Thu Sep  4 11:21:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 11:21:52 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <-yO5kJRg9ghIK9ZHi8auSW22u__Ixsva-A4mvgadZic=.4f31754d-c0a9-4646-a3b7-40aade9678a4@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <uYFYP2iLn3Ol4ZKMCpmlh_3-drv9GOazRdMEQM_1W1c=.37a052a3-63ee-472b-916d-dcc8415160fb@github.com>
 <-yO5kJRg9ghIK9ZHi8auSW22u__Ixsva-A4mvgadZic=.4f31754d-c0a9-4646-a3b7-40aade9678a4@github.com>
Message-ID: <AZKEm7040REVX7fA2IIYKLA5y_SVtnySVjBt9Uy49m0=.77917dd2-de3d-4066-ba68-40c6fe89ae38@github.com>

On Thu, 4 Sep 2025 10:18:27 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/basicLock.hpp line 53:
>> 
>>> 51:   static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }
>>> 52: 
>>> 53:   // For lightweight locking
>> 
>> If the following are for lightweight locking then what are the two previous for?
>
> For something old and soon forgotten. :)
> After I had integrated some platforms I realized that this was no longer needed, but since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

This makes sense to change the displaced header names in BasicLock with the changes to various disp_hdr and other register names in the next cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321704905

From coleenp at openjdk.org  Thu Sep  4 11:21:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 11:21:55 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
 <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
Message-ID: <hMBSttV4Haz0_DDzYERrYojOSEF2r95ljXFreYlrplA=.e9f32226-b3be-499a-9665-5059f89dd0a4@github.com>

On Thu, 4 Sep 2025 02:26:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769:
>> 
>>> 767: 
>>> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated
>>> 769: // ObjectMonitor* when lightweight locking is used. It is used from contexts
>> 
>> I guess you don't need the phrase "when lightweight locking is used".
>
> Even calling it "lightweight locking" is no longer needed.

I think the name "lightweight locking" is used for the file name and class name, so the name is okay.  It does help if you're trying to understand the history of the locking algorithm.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321711418

From coleenp at openjdk.org  Thu Sep  4 11:25:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 11:25:53 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share
In-Reply-To: <CZRSry64icYZhI6xHfZ5_1713lUTvAGk7-NchbVftxI=.e6eb1a58-1fef-45f3-aad7-1d7de95b412c@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
 <CZRSry64icYZhI6xHfZ5_1713lUTvAGk7-NchbVftxI=.e6eb1a58-1fef-45f3-aad7-1d7de95b412c@github.com>
Message-ID: <cYXatz3k_5COQxEHYOY-YXa6GxOSe9YZ6SKQtxNp-oE=.80a9ea35-4724-4f90-97c1-a7d23cead631@github.com>

On Thu, 4 Sep 2025 09:55:23 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.inline.hpp line 48:
>> 
>>> 46:   assert(current == Thread::current(), "must be");
>>> 47: 
>>> 48:     LightweightSynchronizer::enter(obj, lock, current);
>> 
>> In the further RFE, we should remove these dispatch functions too.
>
> Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

So to be clear, we should probably have 2+ RFEs that follow this.  One to remove the cpu specific names like displaced header, one to remove the loom interactions and held_monitor_count, and another to remove the dispatches to LightweightSynchronizer and make ObjectSynchronizer's role in object locking clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321723438

From fbredberg at openjdk.org  Thu Sep  4 11:36:02 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 11:36:02 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v2]
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <hxcBQMZwFekaGf3CW-V2c1AOMG0v2lb69uCNy2pDVP4=.030551cc-729a-41d0-854f-9e22996f27e7@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

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

  Update after review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27041/files
  - new: https://git.openjdk.org/jdk/pull/27041/files/71038b71..3c1b56c5

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

  Stats: 17 lines in 4 files changed: 1 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041

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

From fbredberg at openjdk.org  Thu Sep  4 12:10:01 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 12:10:01 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

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

  New version for Coleen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27041/files
  - new: https://git.openjdk.org/jdk/pull/27041/files/3c1b56c5..f2fc9a5f

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

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

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

From coleenp at openjdk.org  Thu Sep  4 12:10:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 12:10:01 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
Message-ID: <c1Lts9xSz6lsCaqC60pPBdZJx7AD1BkN744G6qaLwzE=.567436f0-fdfa-45fc-b609-ba197b6ef6d9@github.com>

On Thu, 4 Sep 2025 12:07:43 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for Coleen

Looks great!!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3184882023

From fbredberg at openjdk.org  Thu Sep  4 13:03:50 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 13:03:50 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <uTv7hGrRoKhLCxyY2SILmig-HZw0zE5Gh3wNLZ2R1LE=.0d6eb14f-b6aa-464e-9fac-87b829f32f84@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <uTv7hGrRoKhLCxyY2SILmig-HZw0zE5Gh3wNLZ2R1LE=.0d6eb14f-b6aa-464e-9fac-87b829f32f84@github.com>
Message-ID: <A3xR2rgOAyv-WUK_CJLcEYYf2l6kumF_IFmu2SKkRlg=.04caf3b9-4afc-4075-bda9-bf3285ac826e@github.com>

On Tue, 2 Sep 2025 13:46:11 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   New version for Coleen
>
> src/hotspot/share/opto/phaseX.cpp line 1672:
> 
>> 1670:     // Found (linux x64 only?) with:
>> 1671:     //   serviceability/sa/ClhsdbThreadContext.java
>> 1672:     //   -XX:+UnlockExperimentalVMOptions -XX:LockingMode=1 -XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=1110
> 
> For traceability, I suggest leaving this line untouched and adding a comment in the next line clarifying that `-XX:LockingMode` is not available anymore.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322046338

From fbredberg at openjdk.org  Thu Sep  4 13:03:53 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 13:03:53 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
Message-ID: <kJEg8xjAET9XdViA9Ax1temyDx-1bA13Mgwg5oS4v_U=.fce93271-67d1-40b9-9a64-8bc2d21654de@github.com>

On Tue, 2 Sep 2025 20:22:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   New version for Coleen
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 823:
> 
>> 821: ObjectMonitor* LightweightSynchronizer::inflate_into_object_header(oop object, ObjectSynchronizer::InflateCause cause, JavaThread* locking_thread, Thread* current) {
>> 822: 
>> 823:   // The JavaThread* locking_thread parameter is only used by lightweight locking and
> 
> Same here. suggestion:
> 
> 
> // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, or is suspended
> // throughout the call by some other mechanism.

Fixed

> src/hotspot/share/runtime/synchronizer.cpp line 542:
> 
>> 540:   }
>> 541:   ObjectMonitor* monitor;
>> 542:   monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);
> 
> Declare and initialize on the same line:
> 
> ObjectMonitor* monitor = LightwightSynchronizer::inflate_locked_or_imse(obj...);

Fixed

> src/hotspot/share/runtime/synchronizer.cpp line 557:
> 
>> 555: 
>> 556:   ObjectMonitor* monitor;
>> 557:   monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);
> 
> same here with
> ObjectMonitor* monitor = LIght ...
> 
> I think we should have another RFE to look at eliminating the middle call.  Call these in LIghtweightSynchronizer::notify, notifyAll and waitInterruptably directly and remove these functions.

Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322051302
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322052236
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322057900

From fbredberg at openjdk.org  Thu Sep  4 13:03:51 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 4 Sep 2025 13:03:51 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <hMBSttV4Haz0_DDzYERrYojOSEF2r95ljXFreYlrplA=.e9f32226-b3be-499a-9665-5059f89dd0a4@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <YYyG4Y12GO9UncFyZG8Z4vNUfOUIR9le_CBBp7hC54g=.d29ff0c6-8c37-44cd-b24d-35666d094725@github.com>
 <PTY0GwU-8Ah615YhW9AYNPnGR6SjCnEyDW78GrxDtMk=.2a19b8bd-6606-46f5-af68-663c386807ca@github.com>
 <hMBSttV4Haz0_DDzYERrYojOSEF2r95ljXFreYlrplA=.e9f32226-b3be-499a-9665-5059f89dd0a4@github.com>
Message-ID: <KK4Gp9gky9Z6uCNBSkwvUv3e5XIM4Znkm6sejXtbpi0=.2a12cb35-4498-4258-ab96-5333b2736cb3@github.com>

On Thu, 4 Sep 2025 11:19:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Even calling it "lightweight locking" is no longer needed.
>
> I think the name "lightweight locking" is used for the file name and class name, so the name is okay.  It does help if you're trying to understand the history of the locking algorithm.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322050243

From rcastanedalo at openjdk.org  Thu Sep  4 13:34:52 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 4 Sep 2025 13:34:52 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
Message-ID: <k17wvmQmd2nzxOcn9eHhUDOK9ezTo673f6XTsRi5xrw=.68621d5a-054e-4009-a00c-2ad5fe786a57@github.com>

On Thu, 4 Sep 2025 12:10:01 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for Coleen

Compiler changes look good, thanks!

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

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3185331487

From asmehra at openjdk.org  Thu Sep  4 14:01:51 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 4 Sep 2025 14:01:51 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v4]
In-Reply-To: <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
 <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com>
Message-ID: <YLCUUhyKqAtW0CYVh54BpR3vBAFIzw3nJhkJsW9_7jI=.593e58e4-4166-4cae-876b-3e26e092a5bc@github.com>

On Thu, 4 Sep 2025 05:38:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
>> 
>> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker.
>> 
>> All changes are mechanical text replacement. Headers are resorted alphabetically.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fixed include order
>  - Merge branch 'master' into 8366475-rename-metaspace-shared-to-aot-metaspace
>  - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace
>  - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared()
>  - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache
>  - removed unnecessary includes
>  - Redo changes in comments and tests
>  - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace
>  - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017
>  - Rename MetaspaceShared -> AOTMetaspace
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/90a2db1e...63073feb

lgtm

@iklam thanks for addressing the comments.

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

Marked as reviewed by asmehra (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27017#pullrequestreview-3185475117
PR Comment: https://git.openjdk.org/jdk/pull/27017#issuecomment-3253872538

From sjohanss at openjdk.org  Thu Sep  4 14:24:59 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 4 Sep 2025 14:24:59 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field
Message-ID: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>

Please review this enhancement to the smaps parser and printer.

**Summary**
While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.

It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.

For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.

**Testing**
* Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

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

Commit messages:
 - Fix test
 - 8366780: Enhance ProcSmapsParser and Printer to handle THPeligible field

Changes: https://git.openjdk.org/jdk/pull/27098/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366780
  Stats: 20 lines in 4 files changed: 9 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27098/head:pull/27098

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

From kvn at openjdk.org  Thu Sep  4 16:26:56 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Sep 2025 16:26:56 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v4]
In-Reply-To: <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
 <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com>
Message-ID: <BOgs8lZ4P3y5X9Tam4WuUrifKzG40y_21SVrc7j6T6M=.2a8d9f47-1212-4172-bf20-517ff042968c@github.com>

On Thu, 4 Sep 2025 05:38:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
>> 
>> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker.
>> 
>> All changes are mechanical text replacement. Headers are resorted alphabetically.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fixed include order
>  - Merge branch 'master' into 8366475-rename-metaspace-shared-to-aot-metaspace
>  - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace
>  - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared()
>  - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache
>  - removed unnecessary includes
>  - Redo changes in comments and tests
>  - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace
>  - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017
>  - Rename MetaspaceShared -> AOTMetaspace
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/90a2db1e...63073feb

Re-approved

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27017#pullrequestreview-3186112530

From iklam at openjdk.org  Thu Sep  4 16:26:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 16:26:57 GMT
Subject: Integrated: 8366475: Rename MetaspaceShared class to AOTMetaspace
In-Reply-To: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
Message-ID: <_S6QuzRauRjjk57Zs3Xg5aRue8ve7utVf_x1QtQJcHo=.97c23d7f-48d1-43ec-a51c-248a8dff0d74@github.com>

On Sat, 30 Aug 2025 02:21:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
> 
> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker.
> 
> All changes are mechanical text replacement. Headers are resorted alphabetically.

This pull request has now been integrated.

Changeset: f90d5203
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f90d520308d5fa72497dc59bee7258931c2a3d95
Stats:     367 lines in 60 files changed: 35 ins; 35 del; 297 mod

8366475: Rename MetaspaceShared class to AOTMetaspace

Reviewed-by: kvn, asmehra

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

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

From iklam at openjdk.org  Thu Sep  4 16:26:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 16:26:56 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace
In-Reply-To: <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
 <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com>
Message-ID: <mlh152G_KXVVpcyqJLH6L0tVmkPG94l0uWIiNJ3ysd4=.7b70e5b5-35ad-41bb-9400-96c11c3d6142@github.com>

On Sat, 30 Aug 2025 14:15:09 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology):
>> 
>> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker.
>> 
>> All changes are mechanical text replacement. Headers are resorted alphabetically.
>
> @stefank also asked about `INCLUDE_CDS` to replace it with `INCLUDE_AOT`. Should we do this?

Thanks @vnkozlov @ashu-mehra for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27017#issuecomment-3254504004

From ayang at openjdk.org  Thu Sep  4 17:59:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Sep 2025 17:59:41 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field
In-Reply-To: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
Message-ID: <1s0wZ3_PidYtoqUAQ1OrKvCAX8sZGH-yjhpS-OYPjlo=.18a381d1-9158-46af-bf33-d32a509005b8@github.com>

On Thu, 4 Sep 2025 14:19:06 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement to the smaps parser and printer.
> 
> **Summary**
> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
> 
> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
> 
> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
> 
> **Testing**
> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

src/hotspot/os/linux/procMapsParser.hpp line 52:

> 50:   size_t anonhugepages;
> 51:   size_t swap;
> 52:   size_t thpeligible;

Why `size`? Its name sounds like `bool`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2322987857

From lmesnik at openjdk.org  Thu Sep  4 22:41:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 4 Sep 2025 22:41:59 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v4]
In-Reply-To: <sUr2X1WTJd8zxpUNKmck7Kn4SSJ-fyHYyFCa8hngbBc=.492cebbf-02e3-40ef-866a-b5aa1951c985@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <xT5AoTfA0VvTmGZqTuVoZtrBJf4NifwAXF1hR_Jbh5w=.ecffaf10-4c52-4d76-ac34-13a21b2567d1@github.com>
 <sUr2X1WTJd8zxpUNKmck7Kn4SSJ-fyHYyFCa8hngbBc=.492cebbf-02e3-40ef-866a-b5aa1951c985@github.com>
Message-ID: <Adu9XNWrCu37ULJ5cnkSbCp1qvq_JEjyR70HXGrK75E=.19c458fb-4148-47e0-95ab-97cd2a9ccaf8@github.com>

On Wed, 3 Sep 2025 15:56:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Patricio Chilano Mateo <patricio.chilano.mateo at oracle.com>
>>  - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp
>>    
>>    Co-authored-by: Patricio Chilano Mateo <patricio.chilano.mateo at oracle.com>
>
> Marked as reviewed by pchilanomate (Reviewer).

@pchilano, @dholmes-ora, Thank you for review and feedback!

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

PR Comment: https://git.openjdk.org/jdk/pull/26886#issuecomment-3256019766

From lmesnik at openjdk.org  Thu Sep  4 22:55:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 4 Sep 2025 22:55:28 GMT
Subject: Integrated: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding
In-Reply-To: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
Message-ID: <9SuZtN8NJg0ACV05O56wHVaPIUgRgdiZtD4oPKuY1EM=.394f09ed-1b1d-4e93-b91e-96f488470b43@github.com>

On Thu, 21 Aug 2025 15:43:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates
>   `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();`
> to find if method exit normally or by exception.
> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See
> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)`
> where post_method_exit_inner is called directly.
> 
> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. 
> 
> 
> The fix was a part of
> https://github.com/openjdk/jdk/pull/26713
> for
> https://bugs.openjdk.org/browse/JDK-8365192

This pull request has now been integrated.

Changeset: b7b64bb6
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
Stats:     338 lines in 5 files changed: 320 ins; 7 del; 11 mod

8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding

Reviewed-by: dholmes, pchilanomate

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

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

From lmesnik at openjdk.org  Fri Sep  5 01:56:21 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Sep 2025 01:56:21 GMT
Subject: Withdrawn: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <9-gVitzg7qJYfQq3IdXBC3nrlF8Jj9SRrdJN12Y9JXg=.30ff87e7-ae2c-4ba4-9c3b-e6a581705a41@github.com>

On Sat, 9 Aug 2025 20:30:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The method
> get_jvmti_thread_state()
> should be called only while thread is in vm state.
> 
> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state.
> 
> The fix was found using jvmti stress agent and thus no additional regression test is required.

This pull request has been closed without being integrated.

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

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

From sjohanss at openjdk.org  Fri Sep  5 06:26:11 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 06:26:11 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field
In-Reply-To: <1s0wZ3_PidYtoqUAQ1OrKvCAX8sZGH-yjhpS-OYPjlo=.18a381d1-9158-46af-bf33-d32a509005b8@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <1s0wZ3_PidYtoqUAQ1OrKvCAX8sZGH-yjhpS-OYPjlo=.18a381d1-9158-46af-bf33-d32a509005b8@github.com>
Message-ID: <q9qgQpW37prTK8Z0AUHpsMXP6_QUzZgYKeolm7TTyOU=.dba27c26-ccbf-45b1-a274-64fb0c81cdaf@github.com>

On Thu, 4 Sep 2025 17:56:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Please review this enhancement to the smaps parser and printer.
>> 
>> **Summary**
>> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
>> 
>> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
>> 
>> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
>> 
>> **Testing**
>> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.
>
> src/hotspot/os/linux/procMapsParser.hpp line 52:
> 
>> 50:   size_t anonhugepages;
>> 51:   size_t swap;
>> 52:   size_t thpeligible;
> 
> Why `size`? Its name sounds like `bool`?

Yes, it works like a `bool` but I represented it as a number to simply do the parsing similar to the other fields, but I guess I could handle it more like how `VmFlags` are handled.

The the parsing would then look like this, would you prefer that:

if (strncmp(_line, "THPeligible:", 12) == 0) {
  out.thpeligible = ::strstr(_line + 12, "1") != nullptr;
  return;
}


I think I would =)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2324211968

From lmesnik at openjdk.org  Fri Sep  5 06:29:32 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Sep 2025 06:29:32 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state
Message-ID: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>

This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
The related fix here:
https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
Hope fix became clarere now.

There 2 problems in this post_meth_exit:
1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.

The fix adds `post_method_exit_transition` to have single exit point with oop restoration.

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

Commit messages:
 - comment is fixed.
 - fix

Changes: https://git.openjdk.org/jdk/pull/27112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365192
  Stats: 65 lines in 2 files changed: 30 ins; 22 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112

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

From lmesnik at openjdk.org  Fri Sep  5 06:40:31 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Sep 2025 06:40:31 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v2]
In-Reply-To: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
Message-ID: <cB-1FchpaCZmrnNYiD5_Kx_4HilSYHbcXzgoisxfZR4=.b71c0ffe-cd57-4959-a4f5-479cfdfae0b8@github.com>

> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
> The related fix here:
> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
> Hope fix became clarere now.
> 
> There 2 problems in this post_meth_exit:
> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
> 
> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.

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

  comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27112/files
  - new: https://git.openjdk.org/jdk/pull/27112/files/c1de44f6..77c9c7a3

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

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

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

From sjohanss at openjdk.org  Fri Sep  5 07:02:46 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 07:02:46 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v2]
In-Reply-To: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
Message-ID: <64TF7UNv_hZh6HPKn6IjHkxAqe3SidxP8VUqTNb3VyI=.82fdd9a0-bd9b-41e9-8e8a-34cba382b47a@github.com>

> Please review this enhancement to the smaps parser and printer.
> 
> **Summary**
> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
> 
> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
> 
> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
> 
> **Testing**
> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

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

  Albert review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27098/files
  - new: https://git.openjdk.org/jdk/pull/27098/files/197bbdb7..521afbad

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

  Stats: 26 lines in 3 files changed: 7 ins; 6 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27098/head:pull/27098

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

From sjohanss at openjdk.org  Fri Sep  5 07:02:47 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 07:02:47 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v2]
In-Reply-To: <q9qgQpW37prTK8Z0AUHpsMXP6_QUzZgYKeolm7TTyOU=.dba27c26-ccbf-45b1-a274-64fb0c81cdaf@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <1s0wZ3_PidYtoqUAQ1OrKvCAX8sZGH-yjhpS-OYPjlo=.18a381d1-9158-46af-bf33-d32a509005b8@github.com>
 <q9qgQpW37prTK8Z0AUHpsMXP6_QUzZgYKeolm7TTyOU=.dba27c26-ccbf-45b1-a274-64fb0c81cdaf@github.com>
Message-ID: <1B5C3k7B5EkGH0Rso9E3G1cQHb-izDTGEYlggzCQ4mo=.ec94952b-7254-4c8e-ada9-c797dff57f7e@github.com>

On Fri, 5 Sep 2025 06:23:04 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/os/linux/procMapsParser.hpp line 52:
>> 
>>> 50:   size_t anonhugepages;
>>> 51:   size_t swap;
>>> 52:   size_t thpeligible;
>> 
>> Why `size`? Its name sounds like `bool`?
>
> Yes, it works like a `bool` but I represented it as a number to simply do the parsing similar to the other fields, but I guess I could handle it more like how `VmFlags` are handled.
> 
> The the parsing would then look like this, would you prefer that:
> 
> if (strncmp(_line, "THPeligible:", 12) == 0) {
>   out.thpeligible = ::strstr(_line + 12, "1") != nullptr;
>   return;
> }
> 
> 
> I think I would =)

Or actually make use of the unused ?nt` in the code, which I now when looking at the old review realize was used for the THPeligible field (but that parsing was then later removed). 

I'll push a change which does: 

  // scan THPeligible into a bool
  int thpel = 0;
  if (::sscanf(_line, "THPeligible: %d", &thpel) == 1) {
    out.thpeligible = (thpel == 1);
    return;
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2324269607

From sjohanss at openjdk.org  Fri Sep  5 08:33:38 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 08:33:38 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v3]
In-Reply-To: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
Message-ID: <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>

> Please review this enhancement to the smaps parser and printer.
> 
> **Summary**
> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
> 
> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
> 
> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
> 
> **Testing**
> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

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

  Offline comments and discussion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27098/files
  - new: https://git.openjdk.org/jdk/pull/27098/files/521afbad..d9aa3c29

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

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

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

From sjohanss at openjdk.org  Fri Sep  5 08:33:38 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 08:33:38 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v2]
In-Reply-To: <64TF7UNv_hZh6HPKn6IjHkxAqe3SidxP8VUqTNb3VyI=.82fdd9a0-bd9b-41e9-8e8a-34cba382b47a@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <64TF7UNv_hZh6HPKn6IjHkxAqe3SidxP8VUqTNb3VyI=.82fdd9a0-bd9b-41e9-8e8a-34cba382b47a@github.com>
Message-ID: <GQYPV9BGSlRF6N7b-lM1APZjDyrkQKyw3T2SQL3MJ18=.88f1af95-fe52-459f-ae11-2c1adb861f32@github.com>

On Fri, 5 Sep 2025 07:02:46 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to the smaps parser and printer.
>> 
>> **Summary**
>> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
>> 
>> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
>> 
>> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
>> 
>> **Testing**
>> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

After some offline discussion we've decided to not filter away `thpel` for mappings with the `thpad` tag set, because a mapping can have the `thpad` tag but not bet THPeligible. For example if you would `madvise` a too small region. So showing both tags have a value. 

Also changing the order of the THP tags to be in order of significance:
thp - mapping backed by at least one huge page
thpel - OS marked mapping as eligible for huge pages
thpad - JVM requested mapping to be backed by huge pages

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

PR Comment: https://git.openjdk.org/jdk/pull/27098#issuecomment-3257516929

From ayang at openjdk.org  Fri Sep  5 09:27:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Sep 2025 09:27:11 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v3]
In-Reply-To: <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
Message-ID: <Jj7iJXaT6bJfBqfMRstEFwbT6rcVYVmosVnHNPIW5Dw=.9b9c60dc-96e2-49e7-8ca0-df4fe4dfc8c3@github.com>

On Fri, 5 Sep 2025 08:33:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to the smaps parser and printer.
>> 
>> **Summary**
>> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
>> 
>> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
>> 
>> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
>> 
>> **Testing**
>> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Offline comments and discussion

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27098#pullrequestreview-3188630381

From lmesnik at openjdk.org  Fri Sep  5 16:08:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Sep 2025 16:08:13 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v3]
In-Reply-To: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
Message-ID: <AeoEXszIFiPNCza37bOZXegaL8Eh9gOj3DEwxqW3TNk=.580b7232-eaf1-4881-8e19-e9b117cd477e@github.com>

> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
> The related fix here:
> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
> Hope fix became clarere now.
> 
> There 2 problems in this post_meth_exit:
> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
> 
> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.

Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - small improvements
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192-2
 - comment
 - comment is fixed.
 - fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27112/files
  - new: https://git.openjdk.org/jdk/pull/27112/files/77c9c7a3..0bd9c98d

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

  Stats: 997 lines in 48 files changed: 628 ins; 159 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/27112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112

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

From duke at openjdk.org  Fri Sep  5 19:02:02 2025
From: duke at openjdk.org (pf0n)
Date: Fri, 5 Sep 2025 19:02:02 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v3]
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <b1klCGCEqGxrorcHKOssWKVqhivTE-NnZqN5-UZqJ0k=.c0bf62fd-f6a2-4117-a383-7e17f0fb4db3@github.com>

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

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

 - Whitespace
 - Filtering alive objects
 - Filtering alive objects

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26977/files
  - new: https://git.openjdk.org/jdk/pull/26977/files/6a3c6318..4295fed1

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

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

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

From duke at openjdk.org  Fri Sep  5 19:07:29 2025
From: duke at openjdk.org (pf0n)
Date: Fri, 5 Sep 2025 19:07:29 GMT
Subject: RFR: 8366122: Shenandoah: Implement efficient support for object
 count after gc events [v4]
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <3oswYxtSVJyfVg1xsIkus9BfXpNFMEE0cS3tYxH1Mak=.237f1e90-9b60-4b4f-af13-16bb4826b9cc@github.com>

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

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

  Whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26977/files
  - new: https://git.openjdk.org/jdk/pull/26977/files/4295fed1..c7abbbf0

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

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

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

From eastigeevich at openjdk.org  Fri Sep  5 19:15:33 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 5 Sep 2025 19:15:33 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v6]
In-Reply-To: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
Message-ID: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com>

> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
> 
> This PR adds linking a class before the `copy_bytecodes` method is called.
> The PR also adds a regression test.
> 
> Tested fastdebug and release builds: Linux x86_64 and arm64
> - The reproducer from JDK-8277444 passed.
> - The regression test passed.
> - Tier1 - tier3 passed.

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

  Fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26863/files
  - new: https://git.openjdk.org/jdk/pull/26863/files/05207c6c..f442736a

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

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

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

From cjplummer at openjdk.org  Fri Sep  5 19:19:20 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Sep 2025 19:19:20 GMT
Subject: RFR: 8366850: Test com/sun/jdi/JdbStopInNotificationThreadTest.java
 failed
Message-ID: <urlVTTrHV9EpglJVmVnROvhbU2RYc5gDsX0Cs6y5ndY=.6ac51edf-48f1-4b08-97f3-8266f4862dff@github.com>

In order to make this test run faster, its heap size was reduced to 64m. This proved to be too small resulting in sometimes exceeding 10% usage before the notification can be setup. This meant that once the memory consumption loop started, it never stopped until OOME (it's suppose to stop when 10% usage has been achieved). I tried 128m and that also proved to be too small when using ZGC and -Xcomp. 256m seems to be enough. I tested 10x times on all our debug platforms with ZGC, ZGC + -Xcomp, and G1 + -Xcomp.

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

Commit messages:
 - Increase heap size to 256m to avoid OOME

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

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

From cjplummer at openjdk.org  Fri Sep  5 19:23:33 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Sep 2025 19:23:33 GMT
Subject: RFR: 8366850: Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java failed [v2]
In-Reply-To: <urlVTTrHV9EpglJVmVnROvhbU2RYc5gDsX0Cs6y5ndY=.6ac51edf-48f1-4b08-97f3-8266f4862dff@github.com>
References: <urlVTTrHV9EpglJVmVnROvhbU2RYc5gDsX0Cs6y5ndY=.6ac51edf-48f1-4b08-97f3-8266f4862dff@github.com>
Message-ID: <MlAEj0ZsM6pJRbvtauMcryMWUcmmDgC4O_8BqfoozME=.db2855af-56b1-4796-a5e0-13f49b74b101@github.com>

> In order to make this test run faster, its heap size was reduced to 64m. This proved to be too small resulting in sometimes exceeding 10% usage before the notification can be setup. This meant that once the memory consumption loop started, it never stopped until OOME (it's suppose to stop when 10% usage has been achieved). I tried 128m and that also proved to be too small when using ZGC and -Xcomp. 256m seems to be enough. I tested 10x times on all our debug platforms with ZGC, ZGC + -Xcomp, and G1 + -Xcomp.

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

  fix errant problem list edit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27126/files
  - new: https://git.openjdk.org/jdk/pull/27126/files/fe077ab5..417c0c2f

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

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

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

From eastigeevich at openjdk.org  Fri Sep  5 19:33:12 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 5 Sep 2025 19:33:12 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v3]
In-Reply-To: <F5wBMFVi24FTOoSB4vcbDoWTlsw2NeZo7ZDITNRE_vA=.5db8a8e8-d251-40af-8287-51092f871503@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com>
 <F5wBMFVi24FTOoSB4vcbDoWTlsw2NeZo7ZDITNRE_vA=.5db8a8e8-d251-40af-8287-51092f871503@github.com>
Message-ID: <q9Jne1-xoXKM725gN3JeIZv_1jgICAgsXJw3ZSGeFuU=.09a5eef3-58f5-4f23-9a5a-c5ca9b30ee60@github.com>

On Wed, 27 Aug 2025 06:37:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> (I realize this is a tangent, but maybe there is a separate bug here...)
>> 
>>> To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror).
>> 
>> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced:
>> 
>> https://github.com/openjdk/jdk/blob/c75534517729b903b63263cf64dc2ff841e3dcb1/src/hotspot/share/oops/instanceKlass.cpp#L1064
>> 
>> Class.forName(name, false, loader) would result in a prepared class but without the event being sent.
>
>> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced
> 
> @dean-long it seems the JVM TI "prepare" event is somewhat misnamed. It states "At this point, class fields, methods, and implemented interfaces are available, and no code from the class has been executed." but that neither describes preparation, nor the rest of linking. You can only access fields and methods after a class has been initialized! But lets take this elsewhere if needed.

@dholmes-ora, Thank you for review.

> I'm not sure about the test, in particular the attempt to calculate MIN_LINK_TIME_MS. It is very hard to see/know that you will actually induce the desired race. 

Making a reliable regression test was a problem.
`MIN_LINK_TIME_MS` is based on the reproducer from JDK-8277444 and my experiments on x86 and arm64 hosts.
Maybe the time is not the best. As you wrote there is no way to know the race has happened.

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

PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3259506293

From ayang at openjdk.org  Fri Sep  5 19:36:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Sep 2025 19:36:12 GMT
Subject: RFR: 8366850: Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java failed [v2]
In-Reply-To: <MlAEj0ZsM6pJRbvtauMcryMWUcmmDgC4O_8BqfoozME=.db2855af-56b1-4796-a5e0-13f49b74b101@github.com>
References: <urlVTTrHV9EpglJVmVnROvhbU2RYc5gDsX0Cs6y5ndY=.6ac51edf-48f1-4b08-97f3-8266f4862dff@github.com>
 <MlAEj0ZsM6pJRbvtauMcryMWUcmmDgC4O_8BqfoozME=.db2855af-56b1-4796-a5e0-13f49b74b101@github.com>
Message-ID: <V8zaq-zbpOSftA2fsyDYJeuRtsKonenO1gbiE0hsocQ=.8a30b80f-712d-4fa8-be9e-2905669e05fe@github.com>

On Fri, 5 Sep 2025 19:23:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In order to make this test run faster, its heap size was reduced to 64m. This proved to be too small resulting in sometimes exceeding 10% usage before the notification can be setup. This meant that once the memory consumption loop started, it never stopped until OOME (it's suppose to stop when 10% usage has been achieved). I tried 128m and that also proved to be too small when using ZGC and -Xcomp. 256m seems to be enough. I tested 10x times on all our debug platforms with ZGC, ZGC + -Xcomp, and G1 + -Xcomp.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix errant problem list edit

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27126#pullrequestreview-3190563097

From coleenp at openjdk.org  Fri Sep  5 19:38:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 19:38:18 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v6]
In-Reply-To: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com>
Message-ID: <TLhqt4wsUV4o-tX0YTjCdAnvU38LAtfL-TRjbbtehNI=.fba36b76-f29c-4716-9080-393ca904284a@github.com>

On Fri, 5 Sep 2025 19:15:33 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds linking a class before the `copy_bytecodes` method is called.
>> The PR also adds a regression test.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - The regression test passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

If the test becomes problematic because of timing, we could have another change to make it /manual.

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

PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3259525975

From lmesnik at openjdk.org  Fri Sep  5 20:28:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Sep 2025 20:28:13 GMT
Subject: RFR: 8366850: Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java failed [v2]
In-Reply-To: <MlAEj0ZsM6pJRbvtauMcryMWUcmmDgC4O_8BqfoozME=.db2855af-56b1-4796-a5e0-13f49b74b101@github.com>
References: <urlVTTrHV9EpglJVmVnROvhbU2RYc5gDsX0Cs6y5ndY=.6ac51edf-48f1-4b08-97f3-8266f4862dff@github.com>
 <MlAEj0ZsM6pJRbvtauMcryMWUcmmDgC4O_8BqfoozME=.db2855af-56b1-4796-a5e0-13f49b74b101@github.com>
Message-ID: <5L_c-xPO4YDIkvwdP10VGzibhx2x124vTw4TBvEqpeg=.2e6b17b4-6549-4501-adca-5b57b1b1d48d@github.com>

On Fri, 5 Sep 2025 19:23:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In order to make this test run faster, its heap size was reduced to 64m. This proved to be too small resulting in sometimes exceeding 10% usage before the notification can be setup. This meant that once the memory consumption loop started, it never stopped until OOME (it's suppose to stop when 10% usage has been achieved). I tried 128m and that also proved to be too small when using ZGC and -Xcomp. 256m seems to be enough. I tested 10x times on all our debug platforms with ZGC, ZGC + -Xcomp, and G1 + -Xcomp.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix errant problem list edit

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27126#pullrequestreview-3190698248

From syan at openjdk.org  Sat Sep  6 01:36:09 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 6 Sep 2025 01:36:09 GMT
Subject: RFR: 8366850: Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java failed [v2]
In-Reply-To: <MlAEj0ZsM6pJRbvtauMcryMWUcmmDgC4O_8BqfoozME=.db2855af-56b1-4796-a5e0-13f49b74b101@github.com>
References: <urlVTTrHV9EpglJVmVnROvhbU2RYc5gDsX0Cs6y5ndY=.6ac51edf-48f1-4b08-97f3-8266f4862dff@github.com>
 <MlAEj0ZsM6pJRbvtauMcryMWUcmmDgC4O_8BqfoozME=.db2855af-56b1-4796-a5e0-13f49b74b101@github.com>
Message-ID: <w3LJfxandWUe8Zg9USUX4tdamcS6hMdKHvfsiUn1LwI=.afa8a5f3-05a6-46cc-9c1d-a2e5505b40c0@github.com>

On Fri, 5 Sep 2025 19:23:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In order to make this test run faster, its heap size was reduced to 64m. This proved to be too small resulting in sometimes exceeding 10% usage before the notification can be setup. This meant that once the memory consumption loop started, it never stopped until OOME (it's suppose to stop when 10% usage has been achieved). I tried 128m and that also proved to be too small when using ZGC and -Xcomp. 256m seems to be enough. I tested 10x times on all our debug platforms with ZGC, ZGC + -Xcomp, and G1 + -Xcomp.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix errant problem list edit

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27126#pullrequestreview-3191244189

From dholmes at openjdk.org  Mon Sep  8 05:38:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 05:38:15 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
Message-ID: <itpRRA1PnHEhDa3RJ7ihqo4V6QpnyBfMj-o9O2vZUEo=.005d8a89-eb43-4ad0-bbb1-c42a986decf6@github.com>

On Thu, 4 Sep 2025 12:10:01 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for Coleen

Marked as reviewed by dholmes (Reviewer).

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 768:

> 766: }
> 767: 
> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an

Suggestion:

// LightweightSynchronizer::inflate_locked_or_imse is used to get an

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 822:

> 820:   // The JavaThread* locking parameter requires that the
> 821:   // locking_thread == JavaThread::current, or is suspended throughout
> 822:   // the call by some other mechanism.

Suggestion:

  // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, 
  // or is suspended throughout the call by some other mechanism.

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

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3195015687
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329176488
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329179011

From dholmes at openjdk.org  Mon Sep  8 05:57:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 05:57:16 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v3]
In-Reply-To: <AeoEXszIFiPNCza37bOZXegaL8Eh9gOj3DEwxqW3TNk=.580b7232-eaf1-4881-8e19-e9b117cd477e@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
 <AeoEXszIFiPNCza37bOZXegaL8Eh9gOj3DEwxqW3TNk=.580b7232-eaf1-4881-8e19-e9b117cd477e@github.com>
Message-ID: <mpT86haMYhOvcWmzy9bWo9EDcwGCJ-HWlAuZwNcayrE=.1daf4f92-739c-45a9-bc24-ccbd9f3e6c09@github.com>

On Fri, 5 Sep 2025 16:08:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
>> The related fix here:
>> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
>> Hope fix became clarere now.
>> 
>> There 2 problems in this post_meth_exit:
>> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
>> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
>> 
>> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.
>
> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - small improvements
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192-2
>  - comment
>  - comment is fixed.
>  - fix

I've taken a first pass through and the code reorg seems okay. It would have been a little clearer without factoring out the transition method.

Thanks

src/hotspot/share/prims/jvmtiExport.cpp line 1833:

> 1831:   // we just call into the interpreter to convert this into a jvalue.
> 1832:   // The post_method_exit_transition always makes transition to vm and back
> 1833:   // where GC can happen. So it is needed to preserve result  and then restore it

Suggestion:

  // where GC can happen. So it is needed to preserve result and then restore it

src/hotspot/share/prims/jvmtiExport.cpp line 1857:

> 1855:                                     BasicType type, Handle result, jvalue value) {
> 1856:   JvmtiThreadState* state; // should be initialized in vm state only
> 1857:   JavaThread* current = thread; // for JRT_BLOCK

If `thread` is always the current thread then I suggest just calling it `current` in the first place.

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

PR Review: https://git.openjdk.org/jdk/pull/27112#pullrequestreview-3195023988
PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2329182820
PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2329187504

From kbarrett at openjdk.org  Mon Sep  8 06:32:08 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 8 Sep 2025 06:32:08 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
Message-ID: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>

Please review this change that renames the all-static class `Atomic` to
`AtomicAccess`. The reason for this name change is to allow the introduction
of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).

The PR has several commits, according to the specific category of change being
made. It may be easier to review the PR by studying these individual commits.

Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.

There are a number of comments containing the word "Atomic" that I didn't
change. They are generically about atomic operations, and will just as well
serve as referring to the future `Atomic<T>`.

Testing: mach5 tier1, GHA sanity tests.
This is one of those changes where successful builds indicate the change is good.

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

Commit messages:
 - update copyrights
 - misc cleanups
 - fix indentation from rename
 - rename Atomic => AtomicAccess in gtests
 - rename Atomic => AtomicAccess
 - change includes of atomic.hpp in gtests
 - change includes of atomic.hpp
 - rename atomic.hpp => atomicAccess.hpp

Changes: https://git.openjdk.org/jdk/pull/27135/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367014
  Stats: 4894 lines in 427 files changed: 1237 ins; 1235 del; 2422 mod
  Patch: https://git.openjdk.org/jdk/pull/27135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27135/head:pull/27135

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

From fbredberg at openjdk.org  Mon Sep  8 07:08:31 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 8 Sep 2025 07:08:31 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v4]
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

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

  New version for David

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27041/files
  - new: https://git.openjdk.org/jdk/pull/27041/files/f2fc9a5f..905ef3fb

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

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

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

From aboldtch at openjdk.org  Mon Sep  8 07:08:31 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 8 Sep 2025 07:08:31 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v4]
In-Reply-To: <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
Message-ID: <ErZI_8BcW3wmQDxrkOZ3LVUVq3K4Z1K2Y7RaYyuZHWg=.a1b7df24-7ce7-4d81-b8e1-cb0c41c6f0e5@github.com>

On Mon, 8 Sep 2025 07:05:47 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for David

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3195220478

From fbredberg at openjdk.org  Mon Sep  8 07:08:32 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 8 Sep 2025 07:08:32 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v3]
In-Reply-To: <itpRRA1PnHEhDa3RJ7ihqo4V6QpnyBfMj-o9O2vZUEo=.005d8a89-eb43-4ad0-bbb1-c42a986decf6@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com>
 <itpRRA1PnHEhDa3RJ7ihqo4V6QpnyBfMj-o9O2vZUEo=.005d8a89-eb43-4ad0-bbb1-c42a986decf6@github.com>
Message-ID: <rNB90g4uggb8Ldjb7gcVfP9CQUJ1N4xb9UKqPPVWewY=.e42357d0-28d3-4279-8060-0d234967bd09@github.com>

On Mon, 8 Sep 2025 05:33:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   New version for Coleen
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 768:
> 
>> 766: }
>> 767: 
>> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an
> 
> Suggestion:
> 
> // LightweightSynchronizer::inflate_locked_or_imse is used to get an

Fixed

> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 822:
> 
>> 820:   // The JavaThread* locking parameter requires that the
>> 821:   // locking_thread == JavaThread::current, or is suspended throughout
>> 822:   // the call by some other mechanism.
> 
> Suggestion:
> 
>   // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, 
>   // or is suspended throughout the call by some other mechanism.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329325202
PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329325682

From dholmes at openjdk.org  Mon Sep  8 07:24:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 07:24:14 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v4]
In-Reply-To: <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
Message-ID: <nya8oCGxNul7GsrvBrbaDgsQtSbzARALdlQ3aKnCsTo=.8e61be4a-43b6-4d6d-b4ce-5b1bd60586b9@github.com>

On Mon, 8 Sep 2025 07:08:31 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for David

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3195269911

From sroy at openjdk.org  Mon Sep  8 08:19:13 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 8 Sep 2025 08:19:13 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v4]
In-Reply-To: <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
 <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
Message-ID: <P4p8mYqMVH7obDh4bKUoyyKzdIn_vLgFWREujO4bYt8=.a5f92b4e-e9cb-4e24-84a3-0c113de1b30c@github.com>

On Thu, 7 Aug 2025 05:36:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
> 
> Who? me? Other Reviewers? Strange PR description ;-)

I edited the comment here...will edit in the bugs too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3265117328

From dholmes at openjdk.org  Mon Sep  8 08:20:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 08:20:10 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <qssX-7viebmd4gjIHOMjpQpGFuds34Z-4x0U4z8u6ps=.76432e6e-37a8-493a-abd5-9acd0058d8cb@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

LGTM! Thanks for taking this on!

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3195448260

From aph at openjdk.org  Mon Sep  8 09:35:16 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 8 Sep 2025 09:35:16 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

`AtomicAccess` is a bit wordy, and this change is going to mess up diffs for backports terribly, but I can't think of a better way to do it. Thanks.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3195732355

From kbarrett at openjdk.org  Mon Sep  8 09:47:14 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 8 Sep 2025 09:47:14 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com>
Message-ID: <qmpM9lKGFOdN8PFrFkDB_v8GX1--yTbckJca3wbIFMw=.7048968e-f160-4503-845b-b8a901894a97@github.com>

On Mon, 8 Sep 2025 09:32:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

> `AtomicAccess` is a bit wordy, and this change is going to mess up diffs for backports terribly, but I can't think of a better way to do it. Thanks.

There was a bunch of internal to Oracle bike shedding over the names already. But I'm open to more if someone
thinks they have a better idea. Note that once we're all done with switching to `Atomic<T>` where appropriate,
I don't expect very many direct uses of `AtomicAccess` to remain (though there will be _some_).

Diffs for backports are going to get messed up anyway, since most uses of `AtomicAccess` will eventually be
switched over to `Atomic<T>` style usage.

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

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3265464120

From aph at openjdk.org  Mon Sep  8 10:18:14 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 8 Sep 2025 10:18:14 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <qmpM9lKGFOdN8PFrFkDB_v8GX1--yTbckJca3wbIFMw=.7048968e-f160-4503-845b-b8a901894a97@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com>
 <qmpM9lKGFOdN8PFrFkDB_v8GX1--yTbckJca3wbIFMw=.7048968e-f160-4503-845b-b8a901894a97@github.com>
Message-ID: <pBpfy7FUmxGT68RoU28K5VMnHcs9ifJx6GaZkYixsWo=.7b81b442-1b65-405a-b26e-313144c0ecf9@github.com>

On Mon, 8 Sep 2025 09:44:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > `AtomicAccess` is a bit wordy, and this change is going to mess up diffs for backports terribly, but I can't think of a better way to do it. Thanks.
> 
> There was a bunch of internal to Oracle bike shedding over the names already. 

Sure, I imagine there was! It's a shame when decision making happens behind closed doors in a FOSS project, but public list bikeshedding would have been too much for this change.

> Diffs for backports are going to get messed up anyway, since most uses of `AtomicAccess` will eventually be switched over to `Atomic<T>` style usage.

That's fair.

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

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3265596419

From fbredberg at openjdk.org  Mon Sep  8 10:30:29 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 8 Sep 2025 10:30:29 GMT
Subject: RFR: 8365190: Remove LockingMode related code from share [v4]
In-Reply-To: <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
 <nn63Ff47Ae1WC7NwO8B5tWK8CWdpHz4xFkrpJZjtidk=.11850b3f-4f1c-49df-a17d-0f949bd6ed2e@github.com>
Message-ID: <3pd2IyLkKN1NErQilmGDrxPygkH03OTIelZwKZhDkBs=.7a5176ff-395b-4f82-a0eb-ff50ec1401a2@github.com>

On Mon, 8 Sep 2025 07:08:31 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
>> 
>> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
>> 
>> Passes tier1-tier7 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New version for David

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/27041#issuecomment-3265647098

From fbredberg at openjdk.org  Mon Sep  8 10:30:30 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 8 Sep 2025 10:30:30 GMT
Subject: Integrated: 8365190: Remove LockingMode related code from share
In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com>
Message-ID: <8z9GgG5Q8z1MaKgjotL4d7FtJLtrPv_7J0XcQd9gSpo=.f15375ac-ed3b-47da-aada-9ffb10f4eb56@github.com>

On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR).
> 
> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself.
> 
> Passes tier1-tier7 with no added problems.

This pull request has now been integrated.

Changeset: a2726968
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a272696813f2e5e896ac9de9985246aaeb9d476c
Stats:     1277 lines in 50 files changed: 8 ins; 1137 del; 132 mod

8365190: Remove LockingMode related code from share

Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo

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

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

From lmesnik at openjdk.org  Mon Sep  8 15:31:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 8 Sep 2025 15:31:54 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v4]
In-Reply-To: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
Message-ID: <CIz6n75i9AYxfjQ97ECsNIlFOX6h_jfY6hcRHf1zUgM=.1bf79883-45ff-4703-9c12-e4aa7d22af00@github.com>

> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
> The related fix here:
> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
> Hope fix became clarere now.
> 
> There 2 problems in this post_meth_exit:
> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
> 
> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.

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

  reverted to single method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27112/files
  - new: https://git.openjdk.org/jdk/pull/27112/files/0bd9c98d..118d39e1

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

  Stats: 39 lines in 2 files changed: 5 ins; 18 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/27112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112

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

From lmesnik at openjdk.org  Mon Sep  8 15:40:17 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 8 Sep 2025 15:40:17 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
Message-ID: <NuAwYHRT8GPlIoDJXgXXPeII0ZH7sWtsHHiocZfIdVU=.8b08f6df-670b-431e-8476-8784c7f88965@github.com>

> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
> The related fix here:
> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
> Hope fix became clarere now.
> 
> There 2 problems in this post_meth_exit:
> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
> 
> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.

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

  more changes reverted

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27112/files
  - new: https://git.openjdk.org/jdk/pull/27112/files/118d39e1..ea941c2d

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

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

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

From mdoerr at openjdk.org  Mon Sep  8 15:40:17 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 8 Sep 2025 15:40:17 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <NuAwYHRT8GPlIoDJXgXXPeII0ZH7sWtsHHiocZfIdVU=.8b08f6df-670b-431e-8476-8784c7f88965@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
 <NuAwYHRT8GPlIoDJXgXXPeII0ZH7sWtsHHiocZfIdVU=.8b08f6df-670b-431e-8476-8784c7f88965@github.com>
Message-ID: <CQ1RIkWLuP5GRTdI7G8ILcDSXaHvRNITuUxRJ8eMg9U=.45654412-f3a6-4177-bc27-a93d44af60ef@github.com>

On Mon, 8 Sep 2025 15:36:45 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
>> The related fix here:
>> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
>> Hope fix became clarere now.
>> 
>> There 2 problems in this post_meth_exit:
>> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
>> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
>> 
>> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more changes reverted

src/hotspot/share/prims/jvmtiExport.cpp line 1844:

> 1842:   BasicType type = current_frame.interpreter_frame_result(&oop_result, &value);
> 1843:   assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0,
> 1844:           "Stack shouldn't be empty");

I think this assertion needs an adaptation. The expression stack can be empty for native method calls. The result does not necessarily need to be on the expression stack depending on the platform.
Or what else is the reason it is expected to be non-empty?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2330625454

From lmesnik at openjdk.org  Mon Sep  8 15:59:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 8 Sep 2025 15:59:58 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v6]
In-Reply-To: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
Message-ID: <cN-43rHSrjuuDXzXp9CkZHAgm_eulOB6p4Nj40tRov4=.e19dd55a-3d88-49ae-b531-042b08dc407b@github.com>

> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
> The related fix here:
> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
> Hope fix became clarere now.
> 
> There 2 problems in this post_meth_exit:
> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
> 
> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.

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

  comments fixed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27112/files
  - new: https://git.openjdk.org/jdk/pull/27112/files/ea941c2d..03c172a9

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

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

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

From mdoerr at openjdk.org  Mon Sep  8 16:12:12 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 8 Sep 2025 16:12:12 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <CQ1RIkWLuP5GRTdI7G8ILcDSXaHvRNITuUxRJ8eMg9U=.45654412-f3a6-4177-bc27-a93d44af60ef@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
 <NuAwYHRT8GPlIoDJXgXXPeII0ZH7sWtsHHiocZfIdVU=.8b08f6df-670b-431e-8476-8784c7f88965@github.com>
 <CQ1RIkWLuP5GRTdI7G8ILcDSXaHvRNITuUxRJ8eMg9U=.45654412-f3a6-4177-bc27-a93d44af60ef@github.com>
Message-ID: <26fQtgWL5JQWUBmFezDRvr42EDdJbXXUQTl2IAawOKA=.a0b2b356-039e-4828-9d0d-91295f374826@github.com>

On Mon, 8 Sep 2025 15:36:45 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more changes reverted
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1844:
> 
>> 1842:   BasicType type = current_frame.interpreter_frame_result(&oop_result, &value);
>> 1843:   assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0,
>> 1844:           "Stack shouldn't be empty");
> 
> I think this assertion needs an adaptation. The expression stack can be empty for native method calls. The result does not necessarily need to be on the expression stack depending on the platform.
> Or what else is the reason it is expected to be non-empty?

Thanks for adding the native check! Looks good to me, now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2330715809

From lmesnik at openjdk.org  Mon Sep  8 18:31:51 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 8 Sep 2025 18:31:51 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
Message-ID: <TdYaW0Qv36qfaAoiOrOp8pdfZ0iWQfDMMPJQqFWAaks=.f6b1250c-3ac8-4fc8-9362-31fb8565f4fd@github.com>

> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
> The related fix here:
> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
> Hope fix became clarere now.
> 
> There 2 problems in this post_meth_exit:
> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
> 
> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.

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

  interopnly_state should be saved

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27112/files
  - new: https://git.openjdk.org/jdk/pull/27112/files/03c172a9..3a169797

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

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

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

From lmesnik at openjdk.org  Mon Sep  8 18:35:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 8 Sep 2025 18:35:15 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v3]
In-Reply-To: <mpT86haMYhOvcWmzy9bWo9EDcwGCJ-HWlAuZwNcayrE=.1daf4f92-739c-45a9-bc24-ccbd9f3e6c09@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
 <AeoEXszIFiPNCza37bOZXegaL8Eh9gOj3DEwxqW3TNk=.580b7232-eaf1-4881-8e19-e9b117cd477e@github.com>
 <mpT86haMYhOvcWmzy9bWo9EDcwGCJ-HWlAuZwNcayrE=.1daf4f92-739c-45a9-bc24-ccbd9f3e6c09@github.com>
Message-ID: <azSMDI3OcF6er_VJ8_268fH3Cl5nGJoxVQwnSsAgbdI=.356fd0b5-d33a-46a0-a5a2-18f3a9b613fd@github.com>

On Mon, 8 Sep 2025 05:42:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - small improvements
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192-2
>>  - comment
>>  - comment is fixed.
>>  - fix
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1857:
> 
>> 1855:                                     BasicType type, Handle result, jvalue value) {
>> 1856:   JvmtiThreadState* state; // should be initialized in vm state only
>> 1857:   JavaThread* current = thread; // for JRT_BLOCK
> 
> If `thread` is always the current thread then I suggest just calling it `current` in the first place.

This line no remains unchanged. I also reverted some unnecessary changes so let keep fix minimal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2331054856

From cjplummer at openjdk.org  Tue Sep  9 00:09:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 9 Sep 2025 00:09:39 GMT
Subject: Integrated: 8366850: Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java failed
In-Reply-To: <urlVTTrHV9EpglJVmVnROvhbU2RYc5gDsX0Cs6y5ndY=.6ac51edf-48f1-4b08-97f3-8266f4862dff@github.com>
References: <urlVTTrHV9EpglJVmVnROvhbU2RYc5gDsX0Cs6y5ndY=.6ac51edf-48f1-4b08-97f3-8266f4862dff@github.com>
Message-ID: <eBiPbWyDzviiurhnBUmeyWBrik8s6gpvx_dZQ3ja9vk=.0df3242e-0b6f-46b3-a044-77cb7b80df4a@github.com>

On Fri, 5 Sep 2025 19:13:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In order to make this test run faster, its heap size was reduced to 64m. This proved to be too small resulting in sometimes exceeding 10% usage before the notification can be setup. This meant that once the memory consumption loop started, it never stopped until OOME (it's suppose to stop when 10% usage has been achieved). I tried 128m and that also proved to be too small when using ZGC and -Xcomp. 256m seems to be enough. I tested 10x times on all our debug platforms with ZGC, ZGC + -Xcomp, and G1 + -Xcomp.

This pull request has now been integrated.

Changeset: 4ec63e8f
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ec63e8f5d1768ea78d0bbf477d68bcf3c6f96b6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8366850: Test com/sun/jdi/JdbStopInNotificationThreadTest.java failed

Reviewed-by: ayang, lmesnik, syan

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

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

From iklam at openjdk.org  Tue Sep  9 05:27:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 9 Sep 2025 05:27:22 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods
Message-ID: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>

The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls.

This PR is intended to be a strict clean-up that preserves existing behaviors.

The following helper functions are added to simplify boilerplate code in JNI methods.


static Klass* java_lang_Class::as_Klass(jobject java_class);
static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class);

Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread);
InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread);


Notes:

[1] Before this PR, we have both patterns:


java_lang_Class::as_Klass(JNIHandles::resolve(cls));
java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));


If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`.

[2] I refactored `JvmtiThreadState::class_to_verify_considering_redefinition()` so that the caller of this funcation can avoid using `InstanceKlass::cast()`. This is possible because we ONLY store `InstanceKlass*` in `JvmtiThreadState::set_class_being_redefined()`

I also removed a few cases of unnecessary `InstanceKlass::cast()`.

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

Commit messages:
 - more fixes
 - tmp: Clean up java mirror handling in JNI methods

Changes: https://git.openjdk.org/jdk/pull/27158/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27158&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367142
  Stats: 278 lines in 19 files changed: 46 ins; 65 del; 167 mod
  Patch: https://git.openjdk.org/jdk/pull/27158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27158/head:pull/27158

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

From dholmes at openjdk.org  Tue Sep  9 06:01:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Sep 2025 06:01:13 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods
In-Reply-To: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
Message-ID: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com>

On Tue, 9 Sep 2025 05:21:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls.
> 
> This PR is intended to be a strict clean-up that preserves existing behaviors.
> 
> The following helper functions are added to simplify boilerplate code in JNI methods.
> 
> 
> static Klass* java_lang_Class::as_Klass(jobject java_class);
> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
> static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class);
> 
> Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread);
> InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread);
> 
> 
> Notes:
> 
> [1] Before this PR, we have both patterns:
> 
> 
> java_lang_Class::as_Klass(JNIHandles::resolve(cls));
> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));
> 
> 
> If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`.
> 
> [2] I refactored `JvmtiThreadState::class_to_verify_considering_redefinition()` so that the caller of this funcation can avoid using `InstanceKlass::cast()`. This is possible because we ONLY store `InstanceKlass*` in `JvmtiThreadState::set_class_being_redefined()`
> 
> I also removed a few cases of unnecessary `InstanceKlass::cast()`.

Sorry but I think this PR is trying to do too many things at once.

It is pushing JNI resolving inside internal JVM methods, which I think is a bad thing - we resolve JNI references at the boundary to get the oop that the VM wants to work with. Internal APIs should be oblivious to jobject and friends IMO. Also there may be times that the JNI/JVM method needs get the oop itself before extracting the  klass.

You are converting klass to instanceKlass where it has to be instanceKlass e.g. with redefinition. This is a good thing, but it is a very distinct thing that deserves its own cleanup (as per previous changes in that area).

You are defining a helper `java_lang_Class::as_InstanceKlass` to internalize the cast - this is fine but again a simple cleanup that would be better standalone IMO.

It is also not clear that JVM/JNI API's are properly checking that the incoming jobject is in fact a class of the right kind (ie not an array class object).

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3199393023

From iklam at openjdk.org  Tue Sep  9 06:32:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 9 Sep 2025 06:32:14 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods
In-Reply-To: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com>
Message-ID: <qRCJkSqPGayCXaow9fIabG6wyw6vSqx-VJXRm3l7jSE=.5b63123f-d8aa-4367-b615-4fa00f2313c1@github.com>

On Tue, 9 Sep 2025 05:58:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but I think this PR is trying to do too many things at once.
> 
> It is pushing JNI resolving inside internal JVM methods, which I think is a bad thing - we resolve JNI references at the boundary to get the oop that the VM wants to work with. Internal APIs should be oblivious to jobject and friends IMO. Also there may be times that the JNI/JVM method needs get the oop itself before extracting the klass.

There are 92 header files that have the word `jobject` in them. There are 71 cpp/hpp files with the word `JNIHandles::resolve` in them. So I am not sure if we really have that separation anymore.

There are 54 cases where we call `as_Klass(JNIHandles::resolve_non_null(x))`, so I think it would be nice to have a way to write less code.

> You are converting klass to instanceKlass where it has to be instanceKlass e.g. with redefinition. This is a good thing, but it is a very distinct thing that deserves its own cleanup (as per previous changes in that area).


I can move the considering_redefinition changes in a follow-up PR.

> You are defining a helper `java_lang_Class::as_InstanceKlass` to internalize the cast - this is fine but again a simple cleanup that would be better standalone IMO.
> 
> It is also not clear that JVM/JNI API's are properly checking that the incoming jobject is in fact a class of the right kind (ie not an array class object).

I am just converting


InstanceKlass* ik = InstanceKlass::cast(as_Klass(mirror));


to 


InstanceKlass* ik = as_InstanceKlass(mirror);


The code already assumes that it has an InstanceKlass, and I am not changing that.

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3269072414

From dholmes at openjdk.org  Tue Sep  9 06:32:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Sep 2025 06:32:18 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v6]
In-Reply-To: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com>
Message-ID: <bg7UM5JIs9H7Q2Xk5JcmPXg34w58QJLhG9hTfZQXJnI=.fed2201c-a88f-41b3-bcbe-9978a546024b@github.com>

On Fri, 5 Sep 2025 19:15:33 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds linking a class before the `copy_bytecodes` method is called.
>> The PR also adds a regression test.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - The regression test passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Nothing further from me. If there are issues with the test we will address them as needed.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3199565160

From dholmes at openjdk.org  Tue Sep  9 07:00:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Sep 2025 07:00:16 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <TdYaW0Qv36qfaAoiOrOp8pdfZ0iWQfDMMPJQqFWAaks=.f6b1250c-3ac8-4fc8-9362-31fb8565f4fd@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
 <TdYaW0Qv36qfaAoiOrOp8pdfZ0iWQfDMMPJQqFWAaks=.f6b1250c-3ac8-4fc8-9362-31fb8565f4fd@github.com>
Message-ID: <5XlD7SZVcGUSw8qhHTp_aKb2-2IIS9CwEryCrE1GQ1E=.c9de4cab-9e40-423a-9822-851f89835de1@github.com>

On Mon, 8 Sep 2025 18:31:51 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
>> The related fix here:
>> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
>> Hope fix became clarere now.
>> 
>> There 2 problems in this post_meth_exit:
>> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
>> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
>> 
>> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   interopnly_state should be saved

Thanks that looks clearer to me now.

One pre-existing typo.

src/hotspot/share/prims/jvmtiExport.cpp line 1870:

> 1868:   JRT_BLOCK_END
> 1869:   if (interp_only) {
> 1870:     // The JRT_BLOCK_END can safepoint in ThreadInVMfromJava desctructor. Now it is safe to allow

Suggestion:

    // The JRT_BLOCK_END can safepoint in ThreadInVMfromJava destructor. Now it is safe to allow

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27112#pullrequestreview-3199680287
PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2332223595

From dholmes at openjdk.org  Tue Sep  9 07:41:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Sep 2025 07:41:02 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods
In-Reply-To: <qRCJkSqPGayCXaow9fIabG6wyw6vSqx-VJXRm3l7jSE=.5b63123f-d8aa-4367-b615-4fa00f2313c1@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com>
 <qRCJkSqPGayCXaow9fIabG6wyw6vSqx-VJXRm3l7jSE=.5b63123f-d8aa-4367-b615-4fa00f2313c1@github.com>
Message-ID: <bKtwlCNsd9rALHfiJqWYss3GaugNz3rmmqgu-MG19kY=.784fa646-bd0d-47e5-91d0-59a4f88fa923@github.com>

On Tue, 9 Sep 2025 06:29:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> So I am not sure if we really have that separation anymore.

I think it is more that there are many bits of code that actually form the "boundary" (prims, services, some runtime, jvmci, interpreter-related). But I guess it is hard to argue this makes it markedly worse.

> The code already assumes that it has an InstanceKlass, and I am not changing that.

Okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3269331429

From mdoerr at openjdk.org  Tue Sep  9 09:08:40 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 9 Sep 2025 09:08:40 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <TdYaW0Qv36qfaAoiOrOp8pdfZ0iWQfDMMPJQqFWAaks=.f6b1250c-3ac8-4fc8-9362-31fb8565f4fd@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
 <TdYaW0Qv36qfaAoiOrOp8pdfZ0iWQfDMMPJQqFWAaks=.f6b1250c-3ac8-4fc8-9362-31fb8565f4fd@github.com>
Message-ID: <BRpW-aNI-1BQuR2rPv97_s9ooDE3oT5d7BayloUC_zM=.4b2ab2ec-771a-451c-9145-6c768e14c590@github.com>

On Mon, 8 Sep 2025 18:31:51 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
>> The related fix here:
>> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
>> Hope fix became clarere now.
>> 
>> There 2 problems in this post_meth_exit:
>> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
>> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
>> 
>> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   interopnly_state should be saved

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27112#pullrequestreview-3200261168

From stefank at openjdk.org  Tue Sep  9 11:52:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Sep 2025 11:52:03 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

I've checked through the patch and it looks good. I found one file that lacked alignment adjustments.

> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_." and "atomic__." files.

Could you motivate why you chose to not do that?

src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp line 43:

> 41: template<>
> 42: template<typename D, typename I>
> 43: inline D AtomicAccess::PlatformAdd<4>::fetch_then_add(D volatile* dest, I add_value,

This file has multiple alignment issues.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3200998425
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2333148324

From lmesnik at openjdk.org  Tue Sep  9 14:27:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Sep 2025 14:27:53 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v8]
In-Reply-To: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
Message-ID: <yh6Ss9PhFKv4mtRrA_qAMSSvMA75_yJS6V1eOSWxVxA=.57da578b-0c43-4197-a39d-f03513681e32@github.com>

> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
> The related fix here:
> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
> Hope fix became clarere now.
> 
> There 2 problems in this post_meth_exit:
> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
> 
> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.

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

  Update src/hotspot/share/prims/jvmtiExport.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27112/files
  - new: https://git.openjdk.org/jdk/pull/27112/files/3a169797..85482ae4

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

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

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

From mdoerr at openjdk.org  Tue Sep  9 15:51:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 9 Sep 2025 15:51:38 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v8]
In-Reply-To: <yh6Ss9PhFKv4mtRrA_qAMSSvMA75_yJS6V1eOSWxVxA=.57da578b-0c43-4197-a39d-f03513681e32@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
 <yh6Ss9PhFKv4mtRrA_qAMSSvMA75_yJS6V1eOSWxVxA=.57da578b-0c43-4197-a39d-f03513681e32@github.com>
Message-ID: <S9ulykAv1WL3bR6sedD-F2bMESCLmXqzX1ZB_zJr1zk=.2c982357-8f97-46a7-b061-2ec24ae7c98e@github.com>

On Tue, 9 Sep 2025 14:27:53 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
>> The related fix here:
>> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
>> Hope fix became clarere now.
>> 
>> There 2 problems in this post_meth_exit:
>> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
>> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
>> 
>> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/prims/jvmtiExport.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27112#pullrequestreview-3202259586

From iklam at openjdk.org  Tue Sep  9 22:09:06 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 9 Sep 2025 22:09:06 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2]
In-Reply-To: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
Message-ID: <MAkZ2k3-6T_ghGmmgr82XMe1WlX3xUQkjA6zBCKQ16g=.30583140-6410-4cf1-8725-a35c2edcb16b@github.com>

> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls.
> 
> This PR is intended to be a strict clean-up that preserves existing behaviors.
> 
> The following helper functions are added to simplify boilerplate code in JNI methods.
> 
> 
> static Klass* java_lang_Class::as_Klass(jobject java_class);
> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
> static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class);
> 
> Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread);
> InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread);
> 
> 
> Notes:
> 
> [1] Before this PR, we have both patterns:
> 
> 
> java_lang_Class::as_Klass(JNIHandles::resolve(cls));
> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));
> 
> 
> If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`.
> 
> [2] I refactored `JvmtiThreadState::class_to_verify_considering_redefinition()` so that the caller of this funcation can avoid using `InstanceKlass::cast()`. This is possible because we ONLY store `InstanceKlass*` in `JvmtiThreadState::set_class_being_redefined()`
> 
> I also removed a few cases of unnecessary `InstanceKlass::cast()`.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into 8367142-simplify-java-mirror-handling-in-jni-methods
 - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR
 - more fixes
 - tmp: Clean up java mirror handling in JNI methods

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

Changes: https://git.openjdk.org/jdk/pull/27158/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27158&range=01
  Stats: 150 lines in 17 files changed: 20 ins; 32 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/27158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27158/head:pull/27158

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

From iklam at openjdk.org  Tue Sep  9 22:12:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 9 Sep 2025 22:12:48 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2]
In-Reply-To: <bKtwlCNsd9rALHfiJqWYss3GaugNz3rmmqgu-MG19kY=.784fa646-bd0d-47e5-91d0-59a4f88fa923@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com>
 <qRCJkSqPGayCXaow9fIabG6wyw6vSqx-VJXRm3l7jSE=.5b63123f-d8aa-4367-b615-4fa00f2313c1@github.com>
 <bKtwlCNsd9rALHfiJqWYss3GaugNz3rmmqgu-MG19kY=.784fa646-bd0d-47e5-91d0-59a4f88fa923@github.com>
Message-ID: <lNjE6NH07LIlPba6lnHcT9o09laH3aQ2IbKkiTAoY8c=.f589a80a-1300-4885-b6a4-af2cdd025eca@github.com>

On Tue, 9 Sep 2025 07:38:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > So I am not sure if we really have that separation anymore.
> 
> I think it is more that there are many bits of code that actually form the "boundary" (prims, services, some runtime, jvmci, interpreter-related). But I guess it is hard to argue this makes it markedly worse.

Arguably the translation of Java mirrors to Klasses is also a boundary (from Java representation to VM representation) :-)

In reality I think because jobjects are easy to use and are just another kind of handle (like Handle and OopHandle), the leakage from JNI code to other parts of VM just happened naturally.

> > The code already assumes that it has an InstanceKlass, and I am not changing that.
> 
> Okay.

BTW I removed the JVMTI changes from this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3272437346

From serb at openjdk.org  Tue Sep  9 22:19:15 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Sep 2025 22:19:15 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on 32
 bits
Message-ID: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>

On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.

Tested on:
 - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
 - 32-bit: with and without -Xcomp, -Xint, -Xmixed

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

Commit messages:
 - 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on 32 bits

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

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

From serb at openjdk.org  Tue Sep  9 22:19:16 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Sep 2025 22:19:16 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on
 32 bits
In-Reply-To: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
Message-ID: <JJzco_U5WqZLrXf3IGvtKoZ4sLwc_MFSvMll7xcAvv0=.3bd59f23-0b56-4e1b-8196-21e52bc724c0@github.com>

On Tue, 9 Sep 2025 18:16:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.
> 
> Tested on:
>  - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
>  - 32-bit: with and without -Xcomp, -Xint, -Xmixed

The usage of UseCompressedOops was added by the https://github.com/openjdk/jdk/pull/20606

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

PR Comment: https://git.openjdk.org/jdk/pull/27177#issuecomment-3272449915

From lmesnik at openjdk.org  Tue Sep  9 22:47:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Sep 2025 22:47:25 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on
 32 bits
In-Reply-To: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
Message-ID: <eds4FanyuT_9qz5x1Zer2HnQKSmKopyqt71rKc7txMM=.81a05048-39ef-4108-866b-a50261eddf5d@github.com>

On Tue, 9 Sep 2025 18:16:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.
> 
> Tested on:
>  - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
>  - 32-bit: with and without -Xcomp, -Xint, -Xmixed

test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 31:

> 29:  * @comment Don't allow -Xcomp or -Xint as they impact memory useage and number of iterations.
> 30:  *          Require compressed oops because not doing so increases memory usage.
> 31:  * @requires (vm.compMode == "Xmixed") & ((vm.bits == 64 & vm.opt.final.UseCompressedOops) | vm.bits == 32)

would
`@requires (vm.compMode == "Xmixed") & (vm.bits == 32 | vm.opt.final.UseCompressedOops)`
works? (not sure if jtreg is going to evaluate coops mode lazy in this case)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27177#discussion_r2334984865

From serb at openjdk.org  Tue Sep  9 22:47:26 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Sep 2025 22:47:26 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on
 32 bits
In-Reply-To: <eds4FanyuT_9qz5x1Zer2HnQKSmKopyqt71rKc7txMM=.81a05048-39ef-4108-866b-a50261eddf5d@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
 <eds4FanyuT_9qz5x1Zer2HnQKSmKopyqt71rKc7txMM=.81a05048-39ef-4108-866b-a50261eddf5d@github.com>
Message-ID: <qXHygiaivunp9Cd3DEb25OPg-qDheh-FYH2IQKKrBq8=.e2ae0cc9-8e6f-47d8-985b-e07e3e1ae38b@github.com>

On Tue, 9 Sep 2025 22:42:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.
>> 
>> Tested on:
>>  - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
>>  - 32-bit: with and without -Xcomp, -Xint, -Xmixed
>
> test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 31:
> 
>> 29:  * @comment Don't allow -Xcomp or -Xint as they impact memory useage and number of iterations.
>> 30:  *          Require compressed oops because not doing so increases memory usage.
>> 31:  * @requires (vm.compMode == "Xmixed") & ((vm.bits == 64 & vm.opt.final.UseCompressedOops) | vm.bits == 32)
> 
> would
> `@requires (vm.compMode == "Xmixed") & (vm.bits == 32 | vm.opt.final.UseCompressedOops)`
> works? (not sure if jtreg is going to evaluate coops mode lazy in this case)

"bits == 64 & vm.opt.final.UseCompressedOops" is a common pattern used in testbase, so I just followed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27177#discussion_r2334988523

From lmesnik at openjdk.org  Tue Sep  9 23:53:19 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Sep 2025 23:53:19 GMT
Subject: Integrated: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state
In-Reply-To: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
References: <J2Yogyr11dPWug8y1LGflPcLuOAo9-NhYUO9Jr29edw=.3b6ff317-930b-4a87-8cfc-fbe7131245af@github.com>
Message-ID: <7xsRH4FlK6fHdOOzXFFeObrcx9MinJOswOtWT6xG8t8=.13dd022d-6118-4af6-9e60-a94be8659a69@github.com>

On Fri, 5 Sep 2025 06:22:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result.
> The related fix here:
> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56
> Hope fix became clarere now.
> 
> There 2 problems in this post_meth_exit:
> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode.
> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only.
> 
> The fix adds `post_method_exit_transition` to have single exit point with oop restoration.

This pull request has now been integrated.

Changeset: 8cd4e7d8
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8cd4e7d856dcc68243505f4e771dc8ab87176584
Stats:     55 lines in 1 file changed: 24 ins; 20 del; 11 mod

8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state

Reviewed-by: mdoerr, dholmes

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

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

From lmesnik at openjdk.org  Tue Sep  9 23:57:19 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Sep 2025 23:57:19 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on
 32 bits
In-Reply-To: <qXHygiaivunp9Cd3DEb25OPg-qDheh-FYH2IQKKrBq8=.e2ae0cc9-8e6f-47d8-985b-e07e3e1ae38b@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
 <eds4FanyuT_9qz5x1Zer2HnQKSmKopyqt71rKc7txMM=.81a05048-39ef-4108-866b-a50261eddf5d@github.com>
 <qXHygiaivunp9Cd3DEb25OPg-qDheh-FYH2IQKKrBq8=.e2ae0cc9-8e6f-47d8-985b-e07e3e1ae38b@github.com>
Message-ID: <gWxCBkU3vj9UMwgtIZ6Dt3ZXsvuj9wH463bJ5eHw2HE=.77524297-d5f3-4ca4-ad00-6168d18534a9@github.com>

On Tue, 9 Sep 2025 22:44:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 31:
>> 
>>> 29:  * @comment Don't allow -Xcomp or -Xint as they impact memory useage and number of iterations.
>>> 30:  *          Require compressed oops because not doing so increases memory usage.
>>> 31:  * @requires (vm.compMode == "Xmixed") & ((vm.bits == 64 & vm.opt.final.UseCompressedOops) | vm.bits == 32)
>> 
>> would
>> `@requires (vm.compMode == "Xmixed") & (vm.bits == 32 | vm.opt.final.UseCompressedOops)`
>> works? (not sure if jtreg is going to evaluate coops mode lazy in this case)
>
> "bits == 64 & vm.opt.final.UseCompressedOops" is a common pattern used in testbase, so I just followed it.

this common pattern is good to run with specific coops and on 64-bit only, however in your case expression could be simplified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27177#discussion_r2335121999

From serb at openjdk.org  Wed Sep 10 00:29:42 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Sep 2025 00:29:42 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on
 32 bits [v2]
In-Reply-To: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
Message-ID: <tFRqF5BlMduNZB_Qh4LT1nLFw9YkTE2xzuu3CoH75Ms=.a459ef15-56d2-4677-851c-334029b80ae0@github.com>

> On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.
> 
> Tested on:
>  - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
>  - 32-bit: with and without -Xcomp, -Xint, -Xmixed

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

  feedback from the review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27177/files
  - new: https://git.openjdk.org/jdk/pull/27177/files/d33d5518..d404a89a

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

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

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

From serb at openjdk.org  Wed Sep 10 01:00:17 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Sep 2025 01:00:17 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on
 32 bits [v2]
In-Reply-To: <gWxCBkU3vj9UMwgtIZ6Dt3ZXsvuj9wH463bJ5eHw2HE=.77524297-d5f3-4ca4-ad00-6168d18534a9@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
 <eds4FanyuT_9qz5x1Zer2HnQKSmKopyqt71rKc7txMM=.81a05048-39ef-4108-866b-a50261eddf5d@github.com>
 <qXHygiaivunp9Cd3DEb25OPg-qDheh-FYH2IQKKrBq8=.e2ae0cc9-8e6f-47d8-985b-e07e3e1ae38b@github.com>
 <gWxCBkU3vj9UMwgtIZ6Dt3ZXsvuj9wH463bJ5eHw2HE=.77524297-d5f3-4ca4-ad00-6168d18534a9@github.com>
Message-ID: <ic3Op5d0_CFx7H6bGAvZ6YuqX1jwoF8NRs17L7_3M7A=.ef8d42be-e830-4b41-a567-8b7bcb131d9c@github.com>

On Tue, 9 Sep 2025 23:54:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> "bits == 64 & vm.opt.final.UseCompressedOops" is a common pattern used in testbase, so I just followed it.
>
> this common pattern is good to run with specific coops and on 64-bit only, however in your case expression could be simplified.

an updated version works in a same way, tested:
- 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
- 32-bit: with and without -Xcomp, -Xint, -Xmixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27177#discussion_r2335207934

From dlong at openjdk.org  Wed Sep 10 01:09:16 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 10 Sep 2025 01:09:16 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
Message-ID: <AwkHmH0d9__b_S9ycjrMsSJx1lSWIgekneIgiPb4PGM=.37491d2c-9b0b-4d84-88ef-f9555865445d@github.com>

On Tue, 2 Sep 2025 20:52:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert whitespace change
>  - undo debug changes
>  - cleanup

I need one more review for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3272844515

From lmesnik at openjdk.org  Wed Sep 10 01:31:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 10 Sep 2025 01:31:11 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on
 32 bits [v2]
In-Reply-To: <tFRqF5BlMduNZB_Qh4LT1nLFw9YkTE2xzuu3CoH75Ms=.a459ef15-56d2-4677-851c-334029b80ae0@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
 <tFRqF5BlMduNZB_Qh4LT1nLFw9YkTE2xzuu3CoH75Ms=.a459ef15-56d2-4677-851c-334029b80ae0@github.com>
Message-ID: <WzmRNqcHDrqOCZXGWcju3Iv5fofdWq0ys0DzsZ2iwh4=.40712299-6b8d-49ff-93fd-98eb2997ada8@github.com>

On Wed, 10 Sep 2025 00:29:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.
>> 
>> Tested on:
>>  - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
>>  - 32-bit: with and without -Xcomp, -Xint, -Xmixed
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from the review

Thanks for updating.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27177#pullrequestreview-3204003392

From cjplummer at openjdk.org  Wed Sep 10 02:33:12 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Sep 2025 02:33:12 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on
 32 bits [v2]
In-Reply-To: <tFRqF5BlMduNZB_Qh4LT1nLFw9YkTE2xzuu3CoH75Ms=.a459ef15-56d2-4677-851c-334029b80ae0@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
 <tFRqF5BlMduNZB_Qh4LT1nLFw9YkTE2xzuu3CoH75Ms=.a459ef15-56d2-4677-851c-334029b80ae0@github.com>
Message-ID: <4GdPt2VhlOrkObcYmgVkGuaMot5T6sRp_mPSKq9dO0Q=.7e6b33e4-d379-4677-8bda-90ee24139f54@github.com>

On Wed, 10 Sep 2025 00:29:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.
>> 
>> Tested on:
>>  - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
>>  - 32-bit: with and without -Xcomp, -Xint, -Xmixed
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from the review

Please update copyright.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27177#pullrequestreview-3204110440

From dholmes at openjdk.org  Wed Sep 10 07:31:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 07:31:19 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2]
In-Reply-To: <lNjE6NH07LIlPba6lnHcT9o09laH3aQ2IbKkiTAoY8c=.f589a80a-1300-4885-b6a4-af2cdd025eca@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com>
 <qRCJkSqPGayCXaow9fIabG6wyw6vSqx-VJXRm3l7jSE=.5b63123f-d8aa-4367-b615-4fa00f2313c1@github.com>
 <bKtwlCNsd9rALHfiJqWYss3GaugNz3rmmqgu-MG19kY=.784fa646-bd0d-47e5-91d0-59a4f88fa923@github.com>
 <lNjE6NH07LIlPba6lnHcT9o09laH3aQ2IbKkiTAoY8c=.f589a80a-1300-4885-b6a4-af2cdd025eca@github.com>
Message-ID: <uPHp8CpdR8Zi0nYw06hgcYU-3epOmSNUBP4nHiW8T4g=.2783065d-3a1f-4da8-b5ba-8c01fd92edef@github.com>

On Tue, 9 Sep 2025 22:10:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Arguably the translation of Java mirrors to Klasses is also a boundary (from Java representation to VM representation) :-)

The mirror is an oop, both oop and kklass are internal VM representations.

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3273683492

From shade at openjdk.org  Wed Sep 10 07:33:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Sep 2025 07:33:30 GMT
Subject: RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on
 32 bits [v2]
In-Reply-To: <tFRqF5BlMduNZB_Qh4LT1nLFw9YkTE2xzuu3CoH75Ms=.a459ef15-56d2-4677-851c-334029b80ae0@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
 <tFRqF5BlMduNZB_Qh4LT1nLFw9YkTE2xzuu3CoH75Ms=.a459ef15-56d2-4677-851c-334029b80ae0@github.com>
Message-ID: <3D8QSMto7za9fopmE4DDYM-HofiwCllzefWSmqhdr1I=.d60a0eac-487d-456b-badf-3ccf7c12cf85@github.com>

On Wed, 10 Sep 2025 00:29:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.
>> 
>> Tested on:
>>  - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
>>  - 32-bit: with and without -Xcomp, -Xint, -Xmixed
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from the review

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27177#pullrequestreview-3204832917

From kbarrett at openjdk.org  Wed Sep 10 07:34:09 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Sep 2025 07:34:09 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <8HMzxvTwZd1uSZCs528eM4pHsJVeKmFGtplElc8vXpk=.643b3706-7af2-40aa-835c-c3f8a785dd0e@github.com>

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - rename recently added Atomic:: => AtomicAccess::
 - Merge branch 'master' into atomic-access
 - fix prefiously missed arg misalignments
 - rename test_atomic.cpp
 - update copyrights
 - misc cleanups
 - fix indentation from rename
 - rename Atomic => AtomicAccess in gtests
 - rename Atomic => AtomicAccess
 - change includes of atomic.hpp in gtests
 - ... and 2 more: https://git.openjdk.org/jdk/compare/af9b9050...11007c45

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

Changes: https://git.openjdk.org/jdk/pull/27135/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27135&range=01
  Stats: 5577 lines in 430 files changed: 1587 ins; 1585 del; 2405 mod
  Patch: https://git.openjdk.org/jdk/pull/27135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27135/head:pull/27135

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

From kbarrett at openjdk.org  Wed Sep 10 07:34:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Sep 2025 07:34:11 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
Message-ID: <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>

On Tue, 9 Sep 2025 11:49:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> > to not rename the various "atomic_." and "atomic__." files.
> 
> Could you motivate why you chose to not do that?

I thought about it, and waffled back and forth. But I was trying to do as much
as possible of this change mechanically. Renaming a file involves multiple
steps that weren't all easily scriptable. (And I'd already messed up a part of
the renaming of atomic.hpp during patch development.) Also, this change is
going to be hard for backports as it is, and I think renamings might make that
worse. Renamings can also be annoying for archeology. But if you think it's
important...

> src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp line 43:
> 
>> 41: template<>
>> 42: template<typename D, typename I>
>> 43: inline D AtomicAccess::PlatformAdd<4>::fetch_then_add(D volatile* dest, I add_value,
> 
> This file has multiple alignment issues.

Oops, completely missed that file.  Will fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273667707
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2335809380

From kbarrett at openjdk.org  Wed Sep 10 07:34:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Sep 2025 07:34:12 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <rR6GvHDl1M50PWJjcUUruJaWvMEAeTcPK9ubMpkRd28=.ded50ad8-7757-4624-95be-f3d468adb54d@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

Updated for recent commits adding some new uses of `Atomic::` and merge conflicts. Running GHA sanity tests.
mach5 tier1 already passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273675624

From aph at openjdk.org  Wed Sep 10 07:43:37 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 10 Sep 2025 07:43:37 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
 <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
Message-ID: <OYC0XgAFLzN_Kvj9pJZfkQNkg3daoisgjU_lna1CTM0=.a4a18c4d-d501-4461-9976-ff2551a88209@github.com>

On Wed, 10 Sep 2025 07:23:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Also, this change is
> going to be hard for backports as it is, and I think renamings might make that
> worse. Renamings can also be annoying for archeology.

Speaking as an archaeologist and the lead of multiple backport projects, I agree with you, Kim.

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

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273724381

From sroy at openjdk.org  Wed Sep 10 08:06:07 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 10 Sep 2025 08:06:07 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v4]
In-Reply-To: <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
 <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
Message-ID: <-sscVFQjjrzV4-iWqG2DIl4m7sEHC3LEB3EUQ829zQk=.0b50fc02-bf1e-4296-843d-a5cbdbf51f9b@github.com>

On Thu, 7 Aug 2025 05:36:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update ProblemList.txt
>
>> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
>> 
> 
> Who? me? Other Reviewers? Strange PR description ;-)

Hi @tstuefe  Could you kindly review the patch with suggested changes ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3273798917

From stefank at openjdk.org  Wed Sep 10 08:56:25 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 10 Sep 2025 08:56:25 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
 <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
Message-ID: <HRnDxKuZ3LesQsDPfU1YHhv6PijVH6i3lGA7j5a2NdA=.fe6f81b2-0934-40ac-86a6-d3ab6dfd1e81@github.com>

On Wed, 10 Sep 2025 07:23:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> > > to not rename the various "atomic_." and "atomic__." files.
> > 
> > 
> > Could you motivate why you chose to not do that?
> 
> I thought about it, and waffled back and forth. But I was trying to do as much as possible of this change mechanically. Renaming a file involves multiple steps that weren't all easily scriptable. (And I'd already messed up a part of the renaming of atomic.hpp during patch development.) Also, this change is going to be hard for backports as it is, and I think renamings might make that worse. Renamings can also be annoying for archeology. But if you think it's important...

Sure, renames are annoying. I do think that it is bad to leave inconsistent names in a long-lived, evolving code base.

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

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273979685

From stefank at openjdk.org  Wed Sep 10 09:41:38 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 10 Sep 2025 09:41:38 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2]
In-Reply-To: <qRCJkSqPGayCXaow9fIabG6wyw6vSqx-VJXRm3l7jSE=.5b63123f-d8aa-4367-b615-4fa00f2313c1@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com>
 <qRCJkSqPGayCXaow9fIabG6wyw6vSqx-VJXRm3l7jSE=.5b63123f-d8aa-4367-b615-4fa00f2313c1@github.com>
Message-ID: <yxylIcKULapBQ0J_C5gW9eiKPrC2kg7g1LuQ1JeyXdY=.9e08f176-f4cc-4e69-8fd2-90e73a714645@github.com>

On Tue, 9 Sep 2025 06:29:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> There are 54 cases where we call as_Klass(JNIHandles::resolve_non_null(x)), so I think it would be nice to have a way to write less code.

I think you should deal with that by adding a helper function inside jni.cpp instead of extending the *Klass functions to take a jobject.

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3274150749

From dnsimon at openjdk.org  Wed Sep 10 10:02:25 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 10 Sep 2025 10:02:25 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v7]
In-Reply-To: <JJQ9A1Lgs71qGaGkFL62kqbBjcO1LemtX_beYV2ztn0=.aa06a3ab-5ee4-4b6e-95be-2049e0f4817b@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <JJQ9A1Lgs71qGaGkFL62kqbBjcO1LemtX_beYV2ztn0=.aa06a3ab-5ee4-4b6e-95be-2049e0f4817b@github.com>
Message-ID: <CU5wkudYTN8BHF25DUPuGsog9iFcHLuxaO-_xFwrcT0=.3d2b2838-330b-4883-8d35-9988b9434556@github.com>

On Fri, 17 Mar 2023 15:58:35 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Style fixes
>  - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5
>  - Style fixes
>  - SA and JVMCI fixes
>  - Fixes includes and style
>  - SA additional caching from Chris Plummer
>  - Addressing comments from first reviews
>  - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5
>  - Reimplementation of FieldInfo as an unsigned5 stream

One side-effect of this change is that verifying certain old classes (think JCK) can take a long time. For example:

Test.java:

import java.lang.classfile.ClassFile;
import java.lang.constant.ClassDesc;
import static java.lang.constant.ConstantDescs.CD_int;

public class Test {
    public static void main(String[] args) throws Exception {
        int numberOfFields = 65_000;
        ClassDesc classDesc = ClassDesc.of("ManyFieldsClass");

        byte[] classfile = ClassFile.of().build(classDesc, classBuilder -> {
            int flags = ClassFile.ACC_STATIC | ClassFile.ACC_PUBLIC;
            classBuilder.withVersion(ClassFile.JAVA_5_VERSION, 0);
            classBuilder.withField("myField0", CD_int, flags);
            for (int i = 1; i < numberOfFields; i++) {
                classBuilder.withField("myField" + i, CD_int, flags);
            }
        });

        ClassLoader cl = new ClassLoader() {
            @Override
            protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
                if (name.equals("ManyFieldsClass")) {
                    return defineClass(name, classfile, 0, classfile.length);
                }
                return super.loadClass(name, resolve);
            }
        };

        long start = System.currentTimeMillis();
        var c = Class.forName("ManyFieldsClass", true, cl);
        System.out.printf("took %,d ms to load %s%n", (System.currentTimeMillis() - start), c);
    }
}



> java Test.java
took 19,854 ms to load class ManyFieldsClass


Probably not worth worrying about - just wanted to point out something I hit while processing the JCK with Native Image.

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

PR Comment: https://git.openjdk.org/jdk/pull/12855#issuecomment-3274222505

From dholmes at openjdk.org  Wed Sep 10 10:34:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 10:34:41 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2]
In-Reply-To: <MAkZ2k3-6T_ghGmmgr82XMe1WlX3xUQkjA6zBCKQ16g=.30583140-6410-4cf1-8725-a35c2edcb16b@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <MAkZ2k3-6T_ghGmmgr82XMe1WlX3xUQkjA6zBCKQ16g=.30583140-6410-4cf1-8725-a35c2edcb16b@github.com>
Message-ID: <9KIc7fkGt1OyYGBjvqaE4PWdALnulp2hf1zNIT64lHo=.c7dc978f-9e0a-419c-883c-d0cf43ff9155@github.com>

On Tue, 9 Sep 2025 22:09:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls.
>> 
>> This PR is intended to be a strict clean-up that preserves existing behaviors.
>> 
>> The following helper functions are added to simplify boilerplate code in JNI methods.
>> 
>> 
>> static Klass* java_lang_Class::as_Klass(jobject java_class);
>> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
>> static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class);
>> 
>> 
>> Note:
>> 
>> Before this PR, we have both patterns:
>> 
>> 
>> java_lang_Class::as_Klass(JNIHandles::resolve(cls));
>> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));
>> 
>> 
>> If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into 8367142-simplify-java-mirror-handling-in-jni-methods
>  - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR
>  - more fixes
>  - tmp: Clean up java mirror handling in JNI methods

Looks good. A couple of minor nits.

Thanks

src/hotspot/share/prims/jvm.cpp line 844:

> 842:     ResourceMark rm;
> 843:     const char * from_name = java_lang_Class::as_Klass(from)->external_name();
> 844:     const char * to_name = java_lang_Class::as_Klass(result)->external_name();

Suggestion:

    const char* from_name = java_lang_Class::as_Klass(from)->external_name();
    const char* to_name = java_lang_Class::as_Klass(result)->external_name();

pre-existing nit

src/hotspot/share/prims/jvm.cpp line 910:

> 908: 
> 909:   InstanceKlass* lookup_k = java_lang_Class::as_InstanceKlass(lookup);
> 910:   // Lookup class must not be a primitive class (whose mirror null Klass*)

Suggestion:

  // Lookup class must not be a primitive class (whose mirror is a null Klass*)

src/hotspot/share/prims/jvm.cpp line 912:

> 910:   // Lookup class must not be a primitive class (whose mirror null Klass*)
> 911:   if (lookup_k == nullptr) {
> 912:     THROW_MSG_NULL(vmSymbols::java_lang_IllegalArgumentException(), "Lookup class is primitive");

This is a behavioural change.

src/hotspot/share/prims/whitebox.cpp line 2166:

> 2164: 
> 2165: WB_ENTRY(void, WB_LinkClass(JNIEnv* env, jobject wb, jclass clazz))
> 2166:   Klass *k = java_lang_Class::as_Klass(clazz);

Suggestion:

  Klass* k = java_lang_Class::as_Klass(clazz);

src/hotspot/share/prims/whitebox.cpp line 2168:

> 2166:   Klass *k = java_lang_Class::as_Klass(clazz);
> 2167:   if (k->is_instance_klass()) {
> 2168:     InstanceKlass *ik = InstanceKlass::cast(k);

Suggestion:

    InstanceKlass* ik = InstanceKlass::cast(k);

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3205473716
PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336277816
PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336280699
PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336282079
PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336308779
PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336309246

From coleenp at openjdk.org  Wed Sep 10 11:44:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 10 Sep 2025 11:44:29 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2]
In-Reply-To: <yxylIcKULapBQ0J_C5gW9eiKPrC2kg7g1LuQ1JeyXdY=.9e08f176-f4cc-4e69-8fd2-90e73a714645@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com>
 <qRCJkSqPGayCXaow9fIabG6wyw6vSqx-VJXRm3l7jSE=.5b63123f-d8aa-4367-b615-4fa00f2313c1@github.com>
 <yxylIcKULapBQ0J_C5gW9eiKPrC2kg7g1LuQ1JeyXdY=.9e08f176-f4cc-4e69-8fd2-90e73a714645@github.com>
Message-ID: <4YATeT1_12Md5mCSr3ICRHSCfXBu0Ps4ha-rdMz4u_o=.a7bb56a2-b020-49cd-ad25-7618f9ec672e@github.com>

On Wed, 10 Sep 2025 09:39:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There are 54 cases where we call as_Klass(JNIHandles::resolve_non_null(x)), so I think it would be nice to have a way to write less code.

> I think you should deal with that by adding a helper function inside jni.cpp instead of extending the *Klass functions to take a jobject.

I agree with this.  I don't think you should move any more jobjects into the runtime code.  The jobjects should stop at jni/jvm. They don't everywhere but that's something that over time we should fix. For instance, the ci creates jobjects but it should use OopHandles instead, except per-thread OopStorage isn't implemented yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3274573970

From coleenp at openjdk.org  Wed Sep 10 11:48:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 10 Sep 2025 11:48:37 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2]
In-Reply-To: <MAkZ2k3-6T_ghGmmgr82XMe1WlX3xUQkjA6zBCKQ16g=.30583140-6410-4cf1-8725-a35c2edcb16b@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <MAkZ2k3-6T_ghGmmgr82XMe1WlX3xUQkjA6zBCKQ16g=.30583140-6410-4cf1-8725-a35c2edcb16b@github.com>
Message-ID: <3-WDWqpmB2N5SCpzxV0IbpeluWxHBm6RhFE5mkuiiRw=.137799b4-9854-4719-ac9f-85de4937bff4@github.com>

On Tue, 9 Sep 2025 22:09:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls.
>> 
>> This PR is intended to be a strict clean-up that preserves existing behaviors.
>> 
>> The following helper functions are added to simplify boilerplate code in JNI methods.
>> 
>> 
>> static Klass* java_lang_Class::as_Klass(jobject java_class);
>> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
>> static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class);
>> 
>> 
>> Note:
>> 
>> Before this PR, we have both patterns:
>> 
>> 
>> java_lang_Class::as_Klass(JNIHandles::resolve(cls));
>> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));
>> 
>> 
>> If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into 8367142-simplify-java-mirror-handling-in-jni-methods
>  - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR
>  - more fixes
>  - tmp: Clean up java mirror handling in JNI methods

jfr also is a boundary between Java -> Native code. That can have jobjects too, but resolve them before calling javaClasses.

src/hotspot/share/classfile/javaClasses.hpp line 1905:

> 1903: 
> 1904: 
> 1905:   InstanceKlass* klass() const { return vmClasses::klass_at(klass_id); }

Can you fix the indentation?

src/hotspot/share/classfile/javaClasses.inline.hpp line 297:

> 295: inline Klass* java_lang_Class::as_Klass(jobject java_class) {
> 296:   return as_Klass(JNIHandles::resolve_non_null(java_class));
> 297: }

The JNIHandles shouldn't be imported to this file.  The resolve should happen in the caller.

src/hotspot/share/classfile/javaClasses.inline.hpp line 305:

> 303: }
> 304: 
> 305: inline InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class) {

Same here.

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

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3205765862
PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336482267
PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336483940
PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336484858

From eastigeevich at openjdk.org  Wed Sep 10 12:37:22 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 10 Sep 2025 12:37:22 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v6]
In-Reply-To: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com>
Message-ID: <C0GWneWX9mtUKI8nmpphBYxO257-ANJg_moSsltbWls=.3acd4c3c-3ef2-47cc-b251-716bb404fde3@github.com>

On Fri, 5 Sep 2025 19:15:33 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds linking a class before the `copy_bytecodes` method is called.
>> The PR also adds a regression test.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - The regression test passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Thank you, everyone, for reviewing.

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

PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3274751129

From eastigeevich at openjdk.org  Wed Sep 10 12:37:24 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 10 Sep 2025 12:37:24 GMT
Subject: Integrated: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking
In-Reply-To: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
Message-ID: <0TsdFhTcwe221khiTvBTl6JREmQdHtX6-usDKZFpIGM=.9904e049-35f5-4bd2-b95e-96d584e8c6d6@github.com>

On Wed, 20 Aug 2025 15:36:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
> 
> This PR adds linking a class before the `copy_bytecodes` method is called.
> The PR also adds a regression test.
> 
> Tested fastdebug and release builds: Linux x86_64 and arm64
> - The reproducer from JDK-8277444 passed.
> - The regression test passed.
> - Tier1 - tier3 passed.

This pull request has now been integrated.

Changeset: 46ae1ee8
Author:    Evgeny Astigeevich <eastigeevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46ae1ee87152742082e6047d0556944d7ae4567d
Stats:     187 lines in 3 files changed: 186 ins; 0 del; 1 mod

8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking

Reviewed-by: dholmes, amenkov, coleenp

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

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

From serb at openjdk.org  Wed Sep 10 18:45:08 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Sep 2025 18:45:08 GMT
Subject: Integrated: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails
 on 32 bits
In-Reply-To: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
References: <7-Wqayj6GFRt3-AM3Q0g0MrFiDUZpo0teo2kZlPPhzU=.5db42eee-a934-4e12-8358-4da2ce919e9c@github.com>
Message-ID: <OWieZwRDmnp8jJDq3mMWBEfezZQB-ZjvJNKU0x68s9Q=.92596591-2725-4714-aed8-e88c07f7b4f4@github.com>

On Tue, 9 Sep 2025 18:16:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.
> 
> Tested on:
>  - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
>  - 32-bit: with and without -Xcomp, -Xint, -Xmixed

This pull request has now been integrated.

Changeset: fdc11a15
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fdc11a1569248c9b671b66d547b4616aeb953ecf
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on 32 bits

Reviewed-by: lmesnik, cjplummer, shade

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

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

From iklam at openjdk.org  Wed Sep 10 22:46:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Sep 2025 22:46:00 GMT
Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v3]
In-Reply-To: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
Message-ID: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com>

> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new  function:
> 
> 
> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
> 
> 
> This PR is intended to be a strict clean-up that preserves existing behaviors.

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

  Removed the (jobject) version of as_Klass/as_InstanceKlass

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27158/files
  - new: https://git.openjdk.org/jdk/pull/27158/files/d943d2fe..f8634eff

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

  Stats: 70 lines in 9 files changed: 4 ins; 13 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/27158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27158/head:pull/27158

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

From iklam at openjdk.org  Wed Sep 10 22:50:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Sep 2025 22:50:33 GMT
Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java
 mirror to InstanceKlass [v2]
In-Reply-To: <3-WDWqpmB2N5SCpzxV0IbpeluWxHBm6RhFE5mkuiiRw=.137799b4-9854-4719-ac9f-85de4937bff4@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <MAkZ2k3-6T_ghGmmgr82XMe1WlX3xUQkjA6zBCKQ16g=.30583140-6410-4cf1-8725-a35c2edcb16b@github.com>
 <3-WDWqpmB2N5SCpzxV0IbpeluWxHBm6RhFE5mkuiiRw=.137799b4-9854-4719-ac9f-85de4937bff4@github.com>
Message-ID: <qCv4j_iwHSRcALvDFQHF8rxymZq-wBcNcIWnPE52Iqg=.7f102839-52d1-4ac5-968e-5466aba98c5f@github.com>

On Wed, 10 Sep 2025 11:43:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into 8367142-simplify-java-mirror-handling-in-jni-methods
>>  - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR
>>  - more fixes
>>  - tmp: Clean up java mirror handling in JNI methods
>
> src/hotspot/share/classfile/javaClasses.hpp line 1905:
> 
>> 1903: 
>> 1904: 
>> 1905:   InstanceKlass* klass() const { return vmClasses::klass_at(klass_id); }
> 
> Can you fix the indentation?

I removed all indentation alignments from this class, as they no longer seem warranted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2338071887

From iklam at openjdk.org  Wed Sep 10 22:50:30 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Sep 2025 22:50:30 GMT
Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java
 mirror to InstanceKlass [v3]
In-Reply-To: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com>
Message-ID: <bA6Je7U8dR2Ep2vXaMyAYM49qunpAH7P2quZbzvEosA=.dff7afbb-4fcd-46a9-9f11-10947f3be1a9@github.com>

On Wed, 10 Sep 2025 22:46:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new  function:
>> 
>> 
>> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
>> 
>> 
>> This PR is intended to be a strict clean-up that preserves existing behaviors.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the (jobject) version of as_Klass/as_InstanceKlass

I didn't realize that my attempt to remove the `JNIHandles::resolve()` boilerplate can be conversional. I can't put a helper function in jni.cpp because this pattern is used in several files. I've reverted to the old code that makes the explicit calls to `JNIHandles::resolve()`.

I updated the JBS issue text as this PR is now only for reducing the number of InstanceKlass::cast() calls.

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3276767203

From iklam at openjdk.org  Wed Sep 10 22:54:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Sep 2025 22:54:44 GMT
Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java
 mirror to InstanceKlass [v2]
In-Reply-To: <9KIc7fkGt1OyYGBjvqaE4PWdALnulp2hf1zNIT64lHo=.c7dc978f-9e0a-419c-883c-d0cf43ff9155@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <MAkZ2k3-6T_ghGmmgr82XMe1WlX3xUQkjA6zBCKQ16g=.30583140-6410-4cf1-8725-a35c2edcb16b@github.com>
 <9KIc7fkGt1OyYGBjvqaE4PWdALnulp2hf1zNIT64lHo=.c7dc978f-9e0a-419c-883c-d0cf43ff9155@github.com>
Message-ID: <XxNcbwbTUf5qWhst46trSP9t4WCQrVZSEwFeM-0V7b4=.3aab66c0-3a2a-4dac-97d7-46bcb541c5df@github.com>

On Wed, 10 Sep 2025 10:18:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into 8367142-simplify-java-mirror-handling-in-jni-methods
>>  - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR
>>  - more fixes
>>  - tmp: Clean up java mirror handling in JNI methods
>
> src/hotspot/share/prims/jvm.cpp line 912:
> 
>> 910:   // Lookup class must not be a primitive class (whose mirror null Klass*)
>> 911:   if (lookup_k == nullptr) {
>> 912:     THROW_MSG_NULL(vmSymbols::java_lang_IllegalArgumentException(), "Lookup class is primitive");
> 
> This is a behavioural change.

I reverted the change to the error message.

I don't know how we will ever get a primitive class in there and who would be reading the error message. I added a comment saying the error message is wrong, so people reading this code will not get confused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2338076531

From dholmes at openjdk.org  Thu Sep 11 00:41:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Sep 2025 00:41:22 GMT
Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java
 mirror to InstanceKlass [v3]
In-Reply-To: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com>
Message-ID: <dEOMGoklXrLkVTk_5vFs_rxoOTLIm52ahVI_I-CmEFM=.347be73f-0029-4134-8bc6-ad4bfe19e218@github.com>

On Wed, 10 Sep 2025 22:46:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new  function:
>> 
>> 
>> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
>> 
>> 
>> This PR is intended to be a strict clean-up that preserves existing behaviors.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the (jobject) version of as_Klass/as_InstanceKlass

Reduced set of changes still looks good.

I was prepared to be accommodating on the broader change, but seems others agreed with my initial position. :)

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3208294346

From kbarrett at openjdk.org  Thu Sep 11 04:23:16 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 11 Sep 2025 04:23:16 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2]
In-Reply-To: <8HMzxvTwZd1uSZCs528eM4pHsJVeKmFGtplElc8vXpk=.643b3706-7af2-40aa-835c-c3f8a785dd0e@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <8HMzxvTwZd1uSZCs528eM4pHsJVeKmFGtplElc8vXpk=.643b3706-7af2-40aa-835c-c3f8a785dd0e@github.com>
Message-ID: <NwTxewPoW7AdReAVMKC2swb1-QNuERIw_jEmnxbV_Rc=.a231e1f5-1f4b-43ac-8cd9-f0d09bcddaa0@github.com>

On Wed, 10 Sep 2025 07:34:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that renames the all-static class `Atomic` to
>> `AtomicAccess`. The reason for this name change is to allow the introduction
>> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
>> 
>> The PR has several commits, according to the specific category of change being
>> made. It may be easier to review the PR by studying these individual commits.
>> 
>> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
>> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
>> 
>> There are a number of comments containing the word "Atomic" that I didn't
>> change. They are generically about atomic operations, and will just as well
>> serve as referring to the future `Atomic<T>`.
>> 
>> Testing: mach5 tier1, GHA sanity tests.
>> This is one of those changes where successful builds indicate the change is good.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - rename recently added Atomic:: => AtomicAccess::
>  - Merge branch 'master' into atomic-access
>  - fix prefiously missed arg misalignments
>  - rename test_atomic.cpp
>  - update copyrights
>  - misc cleanups
>  - fix indentation from rename
>  - rename Atomic => AtomicAccess in gtests
>  - rename Atomic => AtomicAccess
>  - change includes of atomic.hpp in gtests
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/af9b9050...11007c45

Needs re-review because of updates to deal with merge conflicts and to update newly merged code that needed
the renamings applied. @stefank @theRealAph @dholmes-ora

Hm, now says there is a new merge conflict. Guess you folks should hold off on re-review.

src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp line 118:

> 116:   }
> 117: 
> 118:   void set_value(int value, int bit_mask) {

This and similar changes for arm and riscv came from a merged changeset.
I took that new version and updated it for `Atomic::` => `AtomicAccess::` renaming.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 394:

> 392:       last_recompute_check = os::javaTimeNanos();
> 393:     }
> 394:     DEBUG_ONLY(if (AtomicAccess::load_acquire(&_out_of_stack_walking_enabled)) {)

Another case of taking a merge update and then adjusting for `Atomic::` => `AtomicAccess::`.

src/hotspot/share/runtime/basicLock.inline.hpp line 32:

> 30: #include "runtime/objectMonitor.inline.hpp"
> 31: 
> 32: inline markWord BasicLock::displaced_header() const {

These functions were removed by a merge update.

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

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3277397927
PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3277401578
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2338471419
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2338472405
PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2338473094

From kbarrett at openjdk.org  Thu Sep 11 05:30:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 11 Sep 2025 05:30:11 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v3]
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <2uwnMiCfWvw9BT15Us6UZqTE_JD4-OGNIsjjzZotu9Y=.7efc037c-5d91-4b7b-88be-c48adb659ff6@github.com>

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into atomic-access
 - rename recently added Atomic:: => AtomicAccess::
 - Merge branch 'master' into atomic-access
 - fix prefiously missed arg misalignments
 - rename test_atomic.cpp
 - update copyrights
 - misc cleanups
 - fix indentation from rename
 - rename Atomic => AtomicAccess in gtests
 - rename Atomic => AtomicAccess
 - ... and 3 more: https://git.openjdk.org/jdk/compare/134c3ef4...00ecd55c

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

Changes: https://git.openjdk.org/jdk/pull/27135/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27135&range=02
  Stats: 5577 lines in 430 files changed: 1587 ins; 1585 del; 2405 mod
  Patch: https://git.openjdk.org/jdk/pull/27135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27135/head:pull/27135

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

From dholmes at openjdk.org  Thu Sep 11 06:00:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Sep 2025 06:00:20 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v3]
In-Reply-To: <2uwnMiCfWvw9BT15Us6UZqTE_JD4-OGNIsjjzZotu9Y=.7efc037c-5d91-4b7b-88be-c48adb659ff6@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <2uwnMiCfWvw9BT15Us6UZqTE_JD4-OGNIsjjzZotu9Y=.7efc037c-5d91-4b7b-88be-c48adb659ff6@github.com>
Message-ID: <x0HHZmRFF6qGeazll281IN3i7NAnMwoKN2xMvvtN0fM=.f9be5d61-7f4d-4ef4-854e-fef56501a7d2@github.com>

On Thu, 11 Sep 2025 05:30:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that renames the all-static class `Atomic` to
>> `AtomicAccess`. The reason for this name change is to allow the introduction
>> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
>> 
>> The PR has several commits, according to the specific category of change being
>> made. It may be easier to review the PR by studying these individual commits.
>> 
>> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
>> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
>> 
>> There are a number of comments containing the word "Atomic" that I didn't
>> change. They are generically about atomic operations, and will just as well
>> serve as referring to the future `Atomic<T>`.
>> 
>> Testing: mach5 tier1, GHA sanity tests.
>> This is one of those changes where successful builds indicate the change is good.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into atomic-access
>  - rename recently added Atomic:: => AtomicAccess::
>  - Merge branch 'master' into atomic-access
>  - fix prefiously missed arg misalignments
>  - rename test_atomic.cpp
>  - update copyrights
>  - misc cleanups
>  - fix indentation from rename
>  - rename Atomic => AtomicAccess in gtests
>  - rename Atomic => AtomicAccess
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/134c3ef4...00ecd55c

Still good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3208979512

From stefank at openjdk.org  Thu Sep 11 06:47:16 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 11 Sep 2025 06:47:16 GMT
Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java
 mirror to InstanceKlass [v3]
In-Reply-To: <bA6Je7U8dR2Ep2vXaMyAYM49qunpAH7P2quZbzvEosA=.dff7afbb-4fcd-46a9-9f11-10947f3be1a9@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com>
 <bA6Je7U8dR2Ep2vXaMyAYM49qunpAH7P2quZbzvEosA=.dff7afbb-4fcd-46a9-9f11-10947f3be1a9@github.com>
Message-ID: <5c8zxQ36O0VJk5X7lu5QRuh7LhM49ZdpUTmDV-qc2l4=.9a4c2d95-9a0a-4ba6-8f73-b05e90030f6e@github.com>

On Wed, 10 Sep 2025 22:47:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I didn't realize that my attempt to remove the JNIHandles::resolve() boilerplate can be conversional.

Removing boilerplate wasn't controversial. Spreading the j* types can be seen as controversial give that we have various efforts to push those types out to the boundaries of the JVM. Adding new convenience functions that accept j* goes in the opposite direction. 

> I can't put a helper function in jni.cpp because this pattern is used in several files.

But almost all are in jni.cpp and jvm.cpp and you can get rid of most of the boilerplate code by adding local helpers there. The handfulish of other places could keep their explicit usage of JNIHandles::resolve* calls.

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3278518160

From iklam at openjdk.org  Thu Sep 11 18:34:06 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Sep 2025 18:34:06 GMT
Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java
 mirror to InstanceKlass [v3]
In-Reply-To: <5c8zxQ36O0VJk5X7lu5QRuh7LhM49ZdpUTmDV-qc2l4=.9a4c2d95-9a0a-4ba6-8f73-b05e90030f6e@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com>
 <bA6Je7U8dR2Ep2vXaMyAYM49qunpAH7P2quZbzvEosA=.dff7afbb-4fcd-46a9-9f11-10947f3be1a9@github.com>
 <5c8zxQ36O0VJk5X7lu5QRuh7LhM49ZdpUTmDV-qc2l4=.9a4c2d95-9a0a-4ba6-8f73-b05e90030f6e@github.com>
Message-ID: <uQQRBWC1HS9Y-3gfarwpsyVP0iYetj-XEuiu072WU7c=.6ca259c2-b084-4726-ab77-3b1411ac011f@github.com>

On Thu, 11 Sep 2025 06:44:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > I didn't realize that my attempt to remove the JNIHandles::resolve() boilerplate can be conversional.
> 
> Removing boilerplate wasn't controversial. Spreading the j* types can be seen as controversial give that we have various efforts to push those types out to the boundaries of the JVM. Adding new convenience functions that accept j* goes in the opposite direction.
> 
> > I can't put a helper function in jni.cpp because this pattern is used in several files.
> 
> But almost all are in jni.cpp and jvm.cpp and you can get rid of most of the boilerplate code by adding local helpers there. The handfulish of other places could keep their explicit usage of JNIHandles::resolve* calls.

Maybe in a different PR. I want to keep the current PR simple.

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3282181436

From kbarrett at openjdk.org  Fri Sep 12 06:35:19 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 12 Sep 2025 06:35:19 GMT
Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v3]
In-Reply-To: <OYC0XgAFLzN_Kvj9pJZfkQNkg3daoisgjU_lna1CTM0=.a4a18c4d-d501-4461-9976-ff2551a88209@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
 <iDpU5TCdK05ZWAVCbaI7KAFEn6htGCLJE-4O5Whaf0s=.640b886d-5f1f-45af-b947-7506dd0d97e9@github.com>
 <Mgcv8v1mlWQx038Q1ZXbttfdtwZlc7fEnAfvW8zSIOg=.5391ed7d-974c-400c-a0b6-c69d6b8eb4b4@github.com>
 <OYC0XgAFLzN_Kvj9pJZfkQNkg3daoisgjU_lna1CTM0=.a4a18c4d-d501-4461-9976-ff2551a88209@github.com>
Message-ID: <7AkpbeYv_skWN-uWtPAf4LpJ4stSozu2k0I75xUrAkI=.9aa5463f-4548-4a91-80e1-929f918c0676@github.com>

On Wed, 10 Sep 2025 07:40:38 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
>>> > to not rename the various "atomic_." and "atomic__." files.
>>> 
>>> Could you motivate why you chose to not do that?
>> 
>> I thought about it, and waffled back and forth. But I was trying to do as much
>> as possible of this change mechanically. Renaming a file involves multiple
>> steps that weren't all easily scriptable. (And I'd already messed up a part of
>> the renaming of atomic.hpp during patch development.) Also, this change is
>> going to be hard for backports as it is, and I think renamings might make that
>> worse. Renamings can also be annoying for archeology. But if you think it's
>> important...
>
>> Also, this change is
>> going to be hard for backports as it is, and I think renamings might make that
>> worse. Renamings can also be annoying for archeology.
> 
> Speaking as an archaeologist and the lead of multiple backport projects, I agree with you, Kim.

Thanks for reviews @theRealAph , @stefank , and @dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3283901596

From kbarrett at openjdk.org  Fri Sep 12 06:39:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 12 Sep 2025 06:39:35 GMT
Subject: Integrated: 8367014: Rename class Atomic to AtomicAccess
In-Reply-To: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
References: <p17YB3p-D6kOp-lps-xwRWxHs054inuCWswy9c75UJY=.3ae56781-113a-4ded-9bb8-df84a10aefef@github.com>
Message-ID: <CyoQAAkoPz9RK2zIgnukLtEB6dsDnUqNoKBhjdGPz1E=.55952cab-5558-4ad7-a292-43c8d1e044c0@github.com>

On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames the all-static class `Atomic` to
> `AtomicAccess`. The reason for this name change is to allow the introduction
> of the new type `Atomic<T>` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)).
> 
> The PR has several commits, according to the specific category of change being
> made. It may be easier to review the PR by studying these individual commits.
> 
> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose
> to not rename the various "atomic_<cpu>.*" and "atomic_<os>_<cpu>.*" files.
> 
> There are a number of comments containing the word "Atomic" that I didn't
> change. They are generically about atomic operations, and will just as well
> serve as referring to the future `Atomic<T>`.
> 
> Testing: mach5 tier1, GHA sanity tests.
> This is one of those changes where successful builds indicate the change is good.

This pull request has now been integrated.

Changeset: 9e843f56
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e843f56ec0e4126e8256dff44f47c56e5282d20
Stats:     5577 lines in 430 files changed: 1587 ins; 1585 del; 2405 mod

8367014: Rename class Atomic to AtomicAccess

Reviewed-by: dholmes, aph, stefank

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

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

From duke at openjdk.org  Fri Sep 12 07:58:39 2025
From: duke at openjdk.org (duke)
Date: Fri, 12 Sep 2025 07:58:39 GMT
Subject: Withdrawn: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <CYjrMQ9q7paO0oYq8KGvDJaUV2FpwdJyUFxwY16oeK0=.c1e98154-834e-453d-8a00-c4fae4c1a233@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

This pull request has been closed without being integrated.

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

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

From phubner at openjdk.org  Fri Sep 12 11:36:32 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 11:36:32 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
Message-ID: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>

Hi all,

`FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
1) refactors `constantPoolOop` to be a hidden VM injected field `vmtarget` (name to be consistent with other similar cases),
2) removes `FilteredJavaFieldStream` entirely, and
3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.

Testing: Oracle tiers 1-3.

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

Commit messages:
 - Fix typo.
 - Refactor to purely use injected fields.
 - Remove FilteredJavaFieldStream and usages.
 - Remove constantPoolOop from Java code.
 - Make constantPoolOop a hidden vmholder field.

Changes: https://git.openjdk.org/jdk/pull/27209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365858
  Stats: 194 lines in 9 files changed: 8 ins; 166 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27209/head:pull/27209

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

From sspitsyn at openjdk.org  Fri Sep 12 21:37:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Sep 2025 21:37:05 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v9]
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <sNW43X4dAFqe7pYkLZNPFrGXcLHzNTXFGJOu0m5gvEU=.3191cee6-1bf0-4b7c-a81d-e1a8925bb3ff@github.com>

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 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 nine additional commits since the last revision:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - review: replace RESERVED flag with UNUSED
 - review: keep right order of the obsoleted VM options
 - corrected one assert message
 - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26232/files
  - new: https://git.openjdk.org/jdk/pull/26232/files/df91f171..70a595aa

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

  Stats: 67844 lines in 2326 files changed: 39746 ins; 16876 del; 11222 mod
  Patch: https://git.openjdk.org/jdk/pull/26232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232

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

From fandreuzzi at openjdk.org  Fri Sep 12 21:37:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 12 Sep 2025 21:37:19 GMT
Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused
Message-ID: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>

The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused.

Testing: `tier1`.

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

Commit messages:
 - remove

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

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

From amenkov at openjdk.org  Fri Sep 12 22:09:15 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Sep 2025 22:09:15 GMT
Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused
In-Reply-To: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
References: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
Message-ID: <RZjhYH0D2nPXES4m3Hnns7MA0fzHZazu1WQdzkMLxWM=.abe9ff49-0f13-4321-b25d-6040e04c5f12@github.com>

On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused.
> 
> Testing: `tier1`.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27265#pullrequestreview-3218928154

From cjplummer at openjdk.org  Sat Sep 13 00:28:25 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 13 Sep 2025 00:28:25 GMT
Subject: RFR: 8367297: Test Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java can still fail after
 JDK-8366850
Message-ID: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>

Improved test stability. See first comment for details.

Tested by running the test 25 times with every GC on every supported platform and also combined with -Xcomp.

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

Commit messages:
 - fix jcheck errors
 - improve test stability

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

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

From cjplummer at openjdk.org  Sat Sep 13 00:28:26 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 13 Sep 2025 00:28:26 GMT
Subject: RFR: 8367297: Test Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java can still fail after
 JDK-8366850
In-Reply-To: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
References: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
Message-ID: <A6m-E_OY0jUnPKZ7jBk3_NabeFXPUG0ryLoMS-jhCWg=.f16898bb-63fd-43f9-b4d0-49ed99ca7a54@github.com>

On Sat, 13 Sep 2025 00:19:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Improved test stability. See first comment for details.
> 
> Tested by running the test 25 times with every GC on every supported platform and also combined with -Xcomp.

This test has proven very temperamental and unstable, so I've made a number of changes to address the stability issues.

One realization while working on this was the ZGC youngGen using up the entire heap before a GC was forced, finally promoting to the oldgen and triggering the notification. This put the test at risk of unexpected OOMEs. G1 had a similar issue with delays getting objects promoted. The main way this has been addressed is by adding periodic System.gc() calls. It's not necessary for each call to force the promotion of all objects, but only that they get there over time as more calls are made.

In order to avoid OOME due to the memory consumption loop running faster than the notification can be handled, the test now periodically queries the pool to see if more than 50% has been used. Once that happens it blocks until the notification has been received.

Another tweak was to bump up the threshold to 20%, allowing for using a smaller heap (128m instead of 256m) without risk of exceeding the threshold before the notification is setup, which resulted in timeouts.

The test had no checks to guarantee that the notification was being setup on the oldgen. For most GCs it got lucky and ended up with the right pool. However, for Shenandoah it was not using the right pool. In order to avoid this issue and detect errors with the notification setup, the notification is setup on pools with specific names so we are sure to get the right one.

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

PR Comment: https://git.openjdk.org/jdk/pull/27266#issuecomment-3287233520

From ayang at openjdk.org  Sat Sep 13 13:44:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 13 Sep 2025 13:44:10 GMT
Subject: RFR: 8367297: Test Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java can still fail after
 JDK-8366850
In-Reply-To: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
References: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
Message-ID: <N4iT7wBaWMSgGE1rj4ZF9tZGv3S152_zyB3VkglrRPY=.e224edaa-96cf-4995-9991-c9b502d86f80@github.com>

On Sat, 13 Sep 2025 00:19:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Improved test stability. See first comment for details.
> 
> Tested by running the test 25 times with every GC on every supported platform and also combined with -Xcomp.

test/jdk/com/sun/jdi/JdbStopInNotificationThreadTest.java line 83:

> 81:             counter++;
> 82:             if (counter % 1000 == 0) {
> 83:                 System.gc();       // Encourage promotion into old/tenured generation

I wonder if `fullGC` from `WhiteBox.java` can be used here -- it would make the intention to run full-gc explicit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27266#discussion_r2346652763

From ayang at openjdk.org  Sat Sep 13 13:46:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 13 Sep 2025 13:46:38 GMT
Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused
In-Reply-To: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
References: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
Message-ID: <ub5Bji7QkfqetUzDxCW8j3E8CIorvHI1tbIoTV7zvGk=.f8623463-a411-447a-9dea-90095eb57a9d@github.com>

On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused.
> 
> Testing: `tier1`.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27265#pullrequestreview-3220782480

From duke at openjdk.org  Sat Sep 13 19:15:17 2025
From: duke at openjdk.org (duke)
Date: Sat, 13 Sep 2025 19:15:17 GMT
Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused
In-Reply-To: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
References: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
Message-ID: <TgcdUMgFQT-8LEbyh8QbwoMapfUwI7bNmDh5LeZC324=.a5c85dba-95d5-4b38-b089-d025c1d96723@github.com>

On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused.
> 
> Testing: `tier1`.

@fandreuz 
Your change (at version a2712d42c18830058c1cee6b530c8b9d94b1ecd3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27265#issuecomment-3288747493

From cjplummer at openjdk.org  Sat Sep 13 19:56:27 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 13 Sep 2025 19:56:27 GMT
Subject: RFR: 8367297: Test Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java can still fail after
 JDK-8366850
In-Reply-To: <N4iT7wBaWMSgGE1rj4ZF9tZGv3S152_zyB3VkglrRPY=.e224edaa-96cf-4995-9991-c9b502d86f80@github.com>
References: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
 <N4iT7wBaWMSgGE1rj4ZF9tZGv3S152_zyB3VkglrRPY=.e224edaa-96cf-4995-9991-c9b502d86f80@github.com>
Message-ID: <HgwdnnJ69LkWAUh2ZQf6L2rR5NY6gOpeLbJZSVfg4Tg=.43ce16e5-e566-4385-8a34-01f50636c8d2@github.com>

On Sat, 13 Sep 2025 13:41:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Improved test stability. See first comment for details.
>> 
>> Tested by running the test 25 times with every GC on every supported platform and also combined with -Xcomp.
>
> test/jdk/com/sun/jdi/JdbStopInNotificationThreadTest.java line 83:
> 
>> 81:             counter++;
>> 82:             if (counter % 1000 == 0) {
>> 83:                 System.gc();       // Encourage promotion into old/tenured generation
> 
> I wonder if `fullGC` from `WhiteBox.java` can be used here -- it would make the intention to run full-gc explicit.

Given that the test does not need it to reliably promote 100% into the oldgen on each call, only that allocated objects work there way there over time, I think the System.gc() is fine. It seems to be working well with all GC's, at least in the context of this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27266#discussion_r2346922113

From fandreuzzi at openjdk.org  Sun Sep 14 23:23:27 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sun, 14 Sep 2025 23:23:27 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built with
 Clang
Message-ID: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>

The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:

https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425

In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.

I added some files to the ticket for context.

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

Commit messages:
 - fix
 - simple fix
 - fix
 - fix

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

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

From fandreuzzi at openjdk.org  Sun Sep 14 23:37:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sun, 14 Sep 2025 23:37:02 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v2]
In-Reply-To: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
Message-ID: <r9NFwFU-4cUaVe6jceL6sFfRIBnywxu2wqpcI4r0utk=.9ac3dbd7-70b0-467c-a14b-5588063ffdef@github.com>

> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
> 
> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
> 
> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
> 
> I added some files to the ticket for context.

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

  simplify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27274/files
  - new: https://git.openjdk.org/jdk/pull/27274/files/0c050d35..795338e6

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

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

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

From ayang at openjdk.org  Mon Sep 15 07:46:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 15 Sep 2025 07:46:45 GMT
Subject: RFR: 8367297: Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java can still fail after
 JDK-8366850
In-Reply-To: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
References: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
Message-ID: <3U9nzefRgAPHH85AFaQuCPVFuSleAlXqJkzDgBXliIk=.00502b85-cb03-4aa2-8d66-4e8d0a995245@github.com>

On Sat, 13 Sep 2025 00:19:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Improved test stability. See first comment for details.
> 
> Tested by running the test 25 times with every GC on every supported platform and also combined with -Xcomp.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27266#pullrequestreview-3223285331

From shade at openjdk.org  Mon Sep 15 08:05:20 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Sep 2025 08:05:20 GMT
Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused
In-Reply-To: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
References: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
Message-ID: <uiQ-dVXuSXTbSuAG9nuD4H0dA2rj1oiXDfu7CHBW4Xg=.0e7361e7-33b4-4a71-b0ba-f5a69a0ff196@github.com>

On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused.
> 
> Testing: `tier1`.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27265#pullrequestreview-3223348796

From fandreuzzi at openjdk.org  Mon Sep 15 08:05:21 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 15 Sep 2025 08:05:21 GMT
Subject: Integrated: 8367576: JvmtiThreadState::_debuggable is unused
In-Reply-To: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
References: <y0T1B_DxBQFctN4Yb15Ju44Y3QIEyIkf574_TziNND4=.5382c82f-afb4-4173-b9a8-0e7e831fcfa2@github.com>
Message-ID: <zOgYowHKp28557Ekszg_NyNpaubIErQINUrcJIYhSTY=.6cfb4e73-c0e7-4ee8-ac32-e8e5338e3bb2@github.com>

On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused.
> 
> Testing: `tier1`.

This pull request has now been integrated.

Changeset: c16462b3
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c16462b3b4686982e80fdde6802defafc2de8b1a
Stats:     10 lines in 2 files changed: 0 ins; 10 del; 0 mod

8367576: JvmtiThreadState::_debuggable is unused

Reviewed-by: amenkov, ayang, shade

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

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

From jsjolen at openjdk.org  Mon Sep 15 10:24:52 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 15 Sep 2025 10:24:52 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two
Message-ID: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>

Hi,

This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.

We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.

For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.

On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.

Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

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

Commit messages:
 - Bug
 - Missing inline
 - oops again
 - Oops
 - Docs
 - Another one
 - Simplify further
 - Rename and simplify
 - This is wron
 - Deleting operands

Changes: https://git.openjdk.org/jdk/pull/27198/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367656
  Stats: 728 lines in 11 files changed: 321 ins; 247 del; 160 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

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

From kevinw at openjdk.org  Mon Sep 15 11:54:15 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 15 Sep 2025 11:54:15 GMT
Subject: RFR: 8367297: Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java can still fail after
 JDK-8366850
In-Reply-To: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
References: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
Message-ID: <yImVY6rPVeG4PwL0t-q5ES19-vJki3XI9AaeZrTHbOI=.340d8c5f-53b9-4b56-b56f-347b5b8cb0bb@github.com>

On Sat, 13 Sep 2025 00:19:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Improved test stability. See first comment for details.
> 
> Tested by running the test 25 times with every GC on every supported platform and also combined with -Xcomp.

Some of these are tricky to make reliable, this looks like a valiant effort. 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27266#pullrequestreview-3224237877

From coleenp at openjdk.org  Mon Sep 15 14:25:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Sep 2025 14:25:29 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <HXRziQ5kz7iu8lLRiy7bK3QXgXw0dfkKJecp2vUB8pQ=.66d83f6f-8889-4671-8cb9-72a72030fcb9@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

This looks great.  You said vmtarget but you meant vmholder, which is the right name for this internal field since it points to the mirror (instance of java.lang.Class).

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3224893210

From phubner at openjdk.org  Mon Sep 15 14:25:30 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Sep 2025 14:25:30 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <HXRziQ5kz7iu8lLRiy7bK3QXgXw0dfkKJecp2vUB8pQ=.66d83f6f-8889-4671-8cb9-72a72030fcb9@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <HXRziQ5kz7iu8lLRiy7bK3QXgXw0dfkKJecp2vUB8pQ=.66d83f6f-8889-4671-8cb9-72a72030fcb9@github.com>
Message-ID: <3NcFIVzB54ClBeKBOMpzHFt9gHz-VY5tZGflXHpAXVQ=.f69ec18a-1732-404d-9f0a-c34af33698f1@github.com>

On Mon, 15 Sep 2025 14:19:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks great. You said vmtarget but you meant vmholder, which is the right name for this internal field since it points to the mirror (instance of java.lang.Class).

Apologies, I've updated the PR description accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292440414

From liach at openjdk.org  Mon Sep 15 15:08:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Sep 2025 15:08:59 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

Is `constantPoolOop` in `test/lib/jdk/test/lib/hprof/HprofParser.java` related to this removed field?

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292670063

From phubner at openjdk.org  Mon Sep 15 15:25:54 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Sep 2025 15:25:54 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com>
Message-ID: <BFAPiKK3-gwEPW9pXhaQwlH4SPrfS_pt3UxcTysRIeo=.fcbfb57f-7ead-42d5-8dad-2383f97022f8@github.com>

On Mon, 15 Sep 2025 15:05:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is `constantPoolOop` in `test/lib/jdk/test/lib/hprof/HprofParser.java` related to this removed field?

I'm not sure, I came across this file as well and could not determine if it was an old artefact or not. I had a look at the log message and cross-referenced with HotSpot, and I also went digging in the commit messages, but I could not find anything fruitful. Considering it uses a wildcard and does not reference `sun.reflect.ConstantPool` or `jdk.internal.reflect.ConstantPool` leads me to believe this might be something else, most likely dead code. Many tiers of tests pass. I'm happy to open an issue if you think it's worth looking into.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292742093

From coleenp at openjdk.org  Mon Sep 15 15:45:25 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Sep 2025 15:45:25 GMT
Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java
 mirror to InstanceKlass [v3]
In-Reply-To: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com>
Message-ID: <mEqGBbYhp95wg0EaEPFIlWTRBuul9fmpIFjumelj8yM=.d91bd4f7-a2c1-4115-b460-b02f4b9c8cb9@github.com>

On Wed, 10 Sep 2025 22:46:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new  function:
>> 
>> 
>> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
>> 
>> 
>> This PR is intended to be a strict clean-up that preserves existing behaviors.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the (jobject) version of as_Klass/as_InstanceKlass

This looks great.  Thanks!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3225277530

From liach at openjdk.org  Mon Sep 15 16:06:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Sep 2025 16:06:30 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <VR3FYJNMBflb00WNc1EEnuv5Wvd1CjjPyWsUTngyGBI=.d97fa857-784d-4ddc-b0de-0e4df5ff35b7@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

The removal of this field looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225353180

From coleenp at openjdk.org  Mon Sep 15 16:06:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Sep 2025 16:06:31 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <Bx6fwP7luYX6eCGcAvgjReYacki2TrQOrSSnXPnDg-k=.9cdea86d-febd-42a3-b9b9-93bd1597a2a4@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

ConstantPool in the JVM metadata used to be called constantPoolOop, so I think that's what it's looking to not find.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292895168

From jsjolen at openjdk.org  Mon Sep 15 17:44:39 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 15 Sep 2025 17:44:39 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <Tmcu3Qk7HElp8gKdra-WjnKvtkfkoQY5ofztZ0H7JfY=.dac26a7d-d9fc-4836-9e60-4ce3a0b3cefd@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

Looks good to me!

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225668786

From cjplummer at openjdk.org  Mon Sep 15 18:56:08 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 15 Sep 2025 18:56:08 GMT
Subject: RFR: 8367297: Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java can still fail after
 JDK-8366850
In-Reply-To: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
References: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
Message-ID: <XktMKBzwlcV1VK6jx03TtXh2xXcwOjUTgy-aEAslJQE=.96bd22dc-d1fe-4470-8d8f-a4bf67ca618e@github.com>

On Sat, 13 Sep 2025 00:19:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Improved test stability. See first comment for details.
> 
> Tested by running the test 25 times with every GC on every supported platform and also combined with -Xcomp.

Thank you for the reviews Albert and Kevin!

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

PR Comment: https://git.openjdk.org/jdk/pull/27266#issuecomment-3293492329

From cjplummer at openjdk.org  Mon Sep 15 18:56:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 15 Sep 2025 18:56:09 GMT
Subject: Integrated: 8367297: Test
 com/sun/jdi/JdbStopInNotificationThreadTest.java can still fail after
 JDK-8366850
In-Reply-To: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
References: <kj4N3hQmvvZT20JElLoEf5dMHn5CoGns7qAt-gzLnWU=.18f3028a-23ee-4015-b734-c4d0a46a2ac0@github.com>
Message-ID: <y1Lk0wvX43HwIKfIdPL--Ii71AIEY3OfyzmFkOgj1yw=.b2b41dae-b3be-4fda-96f8-088e550bc1b7@github.com>

On Sat, 13 Sep 2025 00:19:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Improved test stability. See first comment for details.
> 
> Tested by running the test 25 times with every GC on every supported platform and also combined with -Xcomp.

This pull request has now been integrated.

Changeset: 11cdafb8
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11cdafb8216bcd36f6636f7c5663878fb545fb37
Stats:     50 lines in 1 file changed: 36 ins; 1 del; 13 mod

8367297: Test com/sun/jdi/JdbStopInNotificationThreadTest.java can still fail after JDK-8366850

Reviewed-by: ayang, kevinw

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

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

From amenkov at openjdk.org  Mon Sep 15 19:15:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 15 Sep 2025 19:15:26 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <JqcPL4AE_globSRAPoABYNmDI2ABrR56XPOUrgzMZMo=.489d7b11-a2f8-4ea6-a185-6b0e9903a1ce@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

Looks good
I was sure HeapDumper also uses FilteredJavaFieldStream to exclude constantPoolOop field, but it doesn't (I don't remember when it changed and why we didn't have issue with it)

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

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225947841

From cjplummer at openjdk.org  Mon Sep 15 20:17:16 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 15 Sep 2025 20:17:16 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v2]
In-Reply-To: <r9NFwFU-4cUaVe6jceL6sFfRIBnywxu2wqpcI4r0utk=.9ac3dbd7-70b0-467c-a14b-5588063ffdef@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <r9NFwFU-4cUaVe6jceL6sFfRIBnywxu2wqpcI4r0utk=.9ac3dbd7-70b0-467c-a14b-5588063ffdef@github.com>
Message-ID: <gEHq6lfzvSH-dDbUkp8HOCfOuaJYHqUI95ywJ3HINKY=.521ad932-e0a4-4648-a6f0-5969ae011e5a@github.com>

On Sun, 14 Sep 2025 23:37:02 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 432:

> 430:             // We should trust the core dump in this case.
> 431:             continue;
> 432:           }

If this added check passes, then you will ignore any error that may have been caught by the previous page_size and lib_fd checks. It think you will need to redo those here before doing the continue. The other choice is to add this extra check to the original `if` condition, and require that just one of the two  `ROUNDUP(existing_map->memsz, page_size)` checks passes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2349998816

From fandreuzzi at openjdk.org  Mon Sep 15 23:33:25 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 15 Sep 2025 23:33:25 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v3]
In-Reply-To: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
Message-ID: <Tez4Z---FyufKLTsw33tV9oi0uLDJ8PqukpgIWBQhcQ=.d6017d01-9139-4479-a9a4-679d6a3926c6@github.com>

> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
> 
> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
> 
> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
> 
> I added some files to the ticket for context.
> 
> Passes `tier1` and `tier2`.

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27274/files
  - new: https://git.openjdk.org/jdk/pull/27274/files/795338e6..5b594080

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

  Stats: 16 lines in 1 file changed: 5 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27274.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27274/head:pull/27274

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

From fandreuzzi at openjdk.org  Tue Sep 16 00:02:27 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 16 Sep 2025 00:02:27 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v4]
In-Reply-To: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
Message-ID: <czdug0lBsRVPVH4umKFSh12CUTop1adHhUJa9QA19fA=.e44e93d9-3af2-4829-8622-f21b2cb935f1@github.com>

> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
> 
> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
> 
> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
> 
> I added some files to the ticket for context.
> 
> Passes `tier1` and `tier2`.

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

  invert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27274/files
  - new: https://git.openjdk.org/jdk/pull/27274/files/5b594080..b839799d

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

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

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

From fandreuzzi at openjdk.org  Tue Sep 16 00:02:30 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 16 Sep 2025 00:02:30 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v2]
In-Reply-To: <gEHq6lfzvSH-dDbUkp8HOCfOuaJYHqUI95ywJ3HINKY=.521ad932-e0a4-4648-a6f0-5969ae011e5a@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <r9NFwFU-4cUaVe6jceL6sFfRIBnywxu2wqpcI4r0utk=.9ac3dbd7-70b0-467c-a14b-5588063ffdef@github.com>
 <gEHq6lfzvSH-dDbUkp8HOCfOuaJYHqUI95ywJ3HINKY=.521ad932-e0a4-4648-a6f0-5969ae011e5a@github.com>
Message-ID: <Q5wWF0guuMWeuHMzBfuYSaE94R2gakjA9A5Gi91Y284=.fc47372b-052a-4cbe-8485-5849b4a1eb97@github.com>

On Mon, 15 Sep 2025 20:14:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify
>
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 432:
> 
>> 430:             // We should trust the core dump in this case.
>> 431:             continue;
>> 432:           }
> 
> If this added check passes, then you will ignore any error that may have been caught by the previous page_size and lib_fd checks. I think you will need to redo those here before doing the continue. The other choice is to add this extra check to the original `if` condition, and require that just one of the two  `ROUNDUP(existing_map->memsz, page_size)` checks passes.

Thanks for pointing that out, I fixed the problem in 5b5940803c373fa5ea000c673cf52625abaaefb8

Let me know if you see other inconsistencies

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2350352203

From iklam at openjdk.org  Tue Sep 16 01:08:35 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Sep 2025 01:08:35 GMT
Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java
 mirror to InstanceKlass [v3]
In-Reply-To: <uPHp8CpdR8Zi0nYw06hgcYU-3epOmSNUBP4nHiW8T4g=.2783065d-3a1f-4da8-b5ba-8c01fd92edef@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
 <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com>
 <qRCJkSqPGayCXaow9fIabG6wyw6vSqx-VJXRm3l7jSE=.5b63123f-d8aa-4367-b615-4fa00f2313c1@github.com>
 <bKtwlCNsd9rALHfiJqWYss3GaugNz3rmmqgu-MG19kY=.784fa646-bd0d-47e5-91d0-59a4f88fa923@github.com>
 <lNjE6NH07LIlPba6lnHcT9o09laH3aQ2IbKkiTAoY8c=.f589a80a-1300-4885-b6a4-af2cdd025eca@github.com>
 <uPHp8CpdR8Zi0nYw06hgcYU-3epOmSNUBP4nHiW8T4g=.2783065d-3a1f-4da8-b5ba-8c01fd92edef@github.com>
Message-ID: <csXoGNtFsG-O3ZCVmEgRbzO7rPCG2kerKce5QF7ZRQs=.c8319caa-448a-4a2a-af50-616a1504c068@github.com>

On Wed, 10 Sep 2025 07:28:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> > So I am not sure if we really have that separation anymore.
>>> 
>>> I think it is more that there are many bits of code that actually form the "boundary" (prims, services, some runtime, jvmci, interpreter-related). But I guess it is hard to argue this makes it markedly worse.
>> 
>> Arguably the translation of Java mirrors to Klasses is also a boundary (from Java representation to VM representation) :-)
>> 
>> In reality I think because jobjects are easy to use and are just another kind of handle (like Handle and OopHandle), the leakage from JNI code to other parts of VM just happened naturally.
>> 
>>> > The code already assumes that it has an InstanceKlass, and I am not changing that.
>>> 
>>> Okay.
>> 
>> BTW I removed the JVMTI changes from this PR.
>
>> Arguably the translation of Java mirrors to Klasses is also a boundary (from Java representation to VM representation) :-)
> 
> The mirror is an oop, both oop and klass are internal VM representations.

Thanks @dholmes-ora @coleenp for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3294479460

From iklam at openjdk.org  Tue Sep 16 01:08:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Sep 2025 01:08:36 GMT
Subject: Integrated: 8367142: Avoid InstanceKlass::cast when converting java
 mirror to InstanceKlass
In-Reply-To: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
References: <BltkldJwQyKEcZuuYj_px_iPIcQCRNr9L_QCLYxb59w=.ee35c4a9-9987-442a-8232-91f412189267@github.com>
Message-ID: <TDEYYgIGMK9WDlbyCpLu-BKIQtJa3w1-hlBX841uZc4=.e9aec7d7-cb39-4cfc-acd5-9cec5c7cc4c7@github.com>

On Tue, 9 Sep 2025 05:21:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new  function:
> 
> 
> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
> 
> 
> This PR is intended to be a strict clean-up that preserves existing behaviors.

This pull request has now been integrated.

Changeset: 24255848
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/242558484985cb954b0e658776fd59cbca1be1db
Stats:     110 lines in 15 files changed: 9 ins; 30 del; 71 mod

8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass

Reviewed-by: dholmes, coleenp

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

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

From acobbs at openjdk.org  Tue Sep 16 01:49:39 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 Sep 2025 01:49:39 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression
Message-ID: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@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

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

Commit messages:
 - 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.
 - Remove unnecessary -Xlint:-suppression flags.
 - Minor cleanups.
 - Add OPTIONS, PATH, and SUPPRESSION to the regression test.
 - Minor regression test cleanups.
 - Minor comment tweaks.
 - ... and 120 more: https://git.openjdk.org/jdk/compare/11cdafb8...e3283ba9

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344159
  Stats: 1661 lines in 33 files changed: 1485 ins; 51 del; 125 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 iklam at openjdk.org  Tue Sep 16 02:53:04 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Sep 2025 02:53:04 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition()
Message-ID: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>

Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.

I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.

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

Commit messages:
 - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()

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

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

From iklam at openjdk.org  Tue Sep 16 05:27:11 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Sep 2025 05:27:11 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
Message-ID: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>

Goal: simplify AOT implementation and removed unnecessary tests:

This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations).

Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary.

With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production.

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

Commit messages:
 - Added test case for dynamic archive with -javaagent
 - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent

Changes: https://git.openjdk.org/jdk/pull/27304/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27304&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362561
  Stats: 1198 lines in 25 files changed: 41 ins; 1147 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27304.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27304/head:pull/27304

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

From dholmes at openjdk.org  Tue Sep 16 06:35:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Sep 2025 06:35:44 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>

On Wed, 10 Sep 2025 16:19:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Overall this looks good - a lot to digest though, so this is only an initial pass (and I'm not that familiar with the existing code).

Quite a few minor issues (mainly use of `CHECK` macros), some comments and suggestions.

Thanks

src/hotspot/share/classfile/classFileParser.cpp line 3327:

> 3325:                                     bootstrap_methods_u2_len,
> 3326:                                     _loader_data,
> 3327:                                     CHECK);

Suggestion:

    cp->bsm_entries().start_extension(num_bootstrap_methods,
                                      bootstrap_methods_u2_len,
                                      _loader_data,
                                      CHECK);

Fix indent

src/hotspot/share/classfile/classFileParser.cpp line 3338:

> 3336:        "bootstrap_method_index %u has bad constant type in class file %s",
> 3337:        bootstrap_method_ref,
> 3338:                        CHECK);

Suggestion:

       bootstrap_method_ref,
       CHECK);

Fix indent

src/hotspot/share/oops/constantPool.cpp line 53:

> 51: #include "memory/universe.hpp"
> 52: #include "oops/array.hpp"
> 53: #include "oops/constantPool.hpp"

Suggestion:


You don't include the base header if including the .inline.hpp

src/hotspot/share/oops/constantPool.cpp line 1614:

> 1612: ConstantPool::start_extension(const constantPoolHandle& ext_cp, TRAPS) {
> 1613:   return bsm_entries().start_extension(ext_cp->bsm_entries(), pool_holder()->class_loader_data(),
> 1614:                                      CHECK_(BSMAttributeEntries::InsertionIterator()));

You can't use a `CHECK` macro on a return statement - the expansion puts the exception check after the return where it is unreachable.

src/hotspot/share/oops/constantPool.cpp line 1619:

> 1617: 
> 1618: void ConstantPool::end_extension(BSMAttributeEntries::InsertionIterator iter, TRAPS) {
> 1619:   bsm_entries().end_extension(iter, pool_holder()->class_loader_data(), CHECK);

Again no CHECK on a return. In this case all you need is `THREAD`.

src/hotspot/share/oops/constantPool.cpp line 1625:

> 1623: void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp,
> 1624:                                  const constantPoolHandle& to_cp,
> 1625:                                  TRAPS) {

Suggestion:

void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp,
                                    const constantPoolHandle& to_cp,
                                    TRAPS) {

Fix indent

src/hotspot/share/oops/constantPool.cpp line 1628:

> 1626:   to_cp->bsm_entries().append(from_cp->bsm_entries(),
> 1627:                             to_cp->pool_holder()->class_loader_data(),
> 1628:                             CHECK);

Suggestion:

  to_cp->bsm_entries().append(from_cp->bsm_entries(),
                              to_cp->pool_holder()->class_loader_data(),
                              THREAD);

Fix indent, plus (pre-existing) no need for CHECK when you will return anyway.

src/hotspot/share/oops/constantPool.cpp line 1659:

> 1657:     }
> 1658:   }
> 1659:   copy_bsm_entries(from_cp, to_cp, CHECK);

Suggestion:

  copy_bsm_entries(from_cp, to_cp, THREAD);

(pre-existing) no need for CHECK when you will return anyway.

src/hotspot/share/oops/constantPool.cpp line 1831:

> 1829:   const BSMAttributeEntry* const bsmae2 = cp2->bsm_attribute_entry(idx2);
> 1830:   int cp_entry_index1 = bsmae1->bootstrap_method_index();
> 1831:   int cp_entry_index2 = bsmae2->bootstrap_method_index();

The existing simple names are more readable in my opinion.

src/hotspot/share/oops/constantPool.cpp line 1859:

> 1857: // Return the index of a matching bootstrap attribute record or (-1) if there is no match.
> 1858: int ConstantPool::find_matching_bsm_entry(int pattern_i,
> 1859:                     const constantPoolHandle& search_cp, int offset_limit) {

Suggestion:

int ConstantPool::find_matching_bsm_entry(int pattern_i,
                                          const constantPoolHandle& search_cp, int offset_limit) {

Fix indent

src/hotspot/share/oops/constantPool.cpp line 2348:

> 2346:   assert(num_entries + iter._cur_offset <= iter.insert_into->_offsets->length(), "must");
> 2347:   for (int i = 0; i < num_entries; i++) {
> 2348:     const BSMAttributeEntry* bsmae = entry(i);

Nit: It's okay to use a simple name like `e` to represent `entry` - when you don't have different types of entries involved we don't need to encode the type in the variable name. EDIT: just like in `BSMAttributeEntries::InsertionIterator::reserve_new_entry`.

src/hotspot/share/oops/constantPool.cpp line 2355:

> 2353: 
> 2354: BSMAttributeEntries::InsertionIterator BSMAttributeEntries::start_extension(const BSMAttributeEntries& other, ClassLoaderData* loader_data, TRAPS) {
> 2355:   return start_extension(other.number_of_entries(), other.array_length(), loader_data, CHECK_(BSMAttributeEntries::InsertionIterator()));

Again can't use `CHECK_` on a return statement.

src/hotspot/share/oops/constantPool.cpp line 2388:

> 2386:   InsertionIterator iter = start_extension(other, loader_data, CHECK);
> 2387:   other.copy_into(iter, other.number_of_entries());
> 2388:   end_extension(iter, loader_data, CHECK);

Again no need for CHECK on final statement.

src/hotspot/share/oops/constantPool.cpp line 2393:

> 2391: 
> 2392: void BSMAttributeEntries::end_extension(InsertionIterator& iter, ClassLoaderData* loader_data,
> 2393:                                       TRAPS) {

Suggestion:

void BSMAttributeEntries::end_extension(InsertionIterator& iter, ClassLoaderData* loader_data, TRAPS) {

This line is still shorter than 2382 above

src/hotspot/share/oops/constantPool.hpp line 145:

> 143:     : insert_into(insert_into),
> 144:       _cur_offset(cur_offset),
> 145:       _cur_array(cur_array) {}

Not sure what the indentation rules are for constructors but I think we need some more.

src/hotspot/share/oops/constantPool.hpp line 200:

> 198:   // Extend to have the space for both this BSMAEntries and other's.
> 199:   // Does not copy in the other's BSMAEntrys, that must be done via the InsertionIterator.
> 200:   // This starts an insertion iterator. Any call to start_extension must have a matching end_exntesion call.

Suggestion:

  // This starts an insertion iterator. Any call to start_extension must have a matching end_extension call.

src/hotspot/share/oops/constantPool.hpp line 224:

> 222:   InstanceKlass*       _pool_holder; // the corresponding class
> 223: 
> 224:   BSMAttributeEntries _bsmaentries;

Nit: `_entries` would suffice.

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 394:

> 392:   write_attribute_name_index("BootstrapMethods");
> 393:   u4 length = sizeof(u2) + // num_bootstrap_methods
> 394:               // The rest of it

The comment doesn't add any value here.

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 398:

> 396:   write_u4(length);
> 397: 
> 398:   int num_bootstrap_methods = cpool()->bsm_entries().number_of_entries();

I'm confused about the seemingly different uses of `num_bootstrap_methods` here and in the comment above:

sizeof(u2) + // num_bootstrap_methods

?

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 49:

> 47: #include "oops/annotations.hpp"
> 48: #include "oops/constantPool.hpp"
> 49: #include "oops/constantPool.inline.hpp"

Suggestion:

#include "oops/constantPool.inline.hpp"

You don't include the regular header when you include the inline one.

src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 371:

> 369:   intArray *                  _bsm_index_map_p;
> 370: 
> 371:   // After merge_constant_pools pass 0 the BSMAttribute entries of merge_cp_p will have been expanded to fit scratch_cp.

This comment doesn't read correctly.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 444:

> 442:         a = bsmaentries_offsets.getValue(a);
> 443:         return VMObjectFactory.newObject(U4Array.class, a);
> 444:   }

Suggestion:

  private U4Array getOffsets() {
     Address a =  getAddress().addOffsetTo(bsmaentries);
     if (a == null) return null;
     a = bsmaentries_offsets.getValue(a);
     return VMObjectFactory.newObject(U4Array.class, a);
  }

Fix indent. (Note this file is using  2-indent instead of the 4-indent it should for Java code.)

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3227461452
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350904057
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350905434
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350911716
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350919770
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350921555
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350923178
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350926508
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350929316
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350937167
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350939688
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350948252
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350949299
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350952103
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350954308
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350974468
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350977926
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350979954
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350990306
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350994934
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350996928
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351002821
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351014174

From dholmes at openjdk.org  Tue Sep 16 06:44:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Sep 2025 06:44:33 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition()
In-Reply-To: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
Message-ID: <dqOj9UEjjL0fodNbTx6JqoYi-WvnlYnU6dYoaXJle9M=.b06de883-d892-4f88-97e4-88a6883e7194@github.com>

On Tue, 16 Sep 2025 02:44:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.
> 
> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.

Looks good. Just some minor nits.

Thanks

src/hotspot/share/prims/jvm.cpp line 2263:

> 2261: // Please, refer to the description in the jvmtiThreadState.hpp.
> 2262: 
> 2263: inline Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread) {

Suggestion:

inline Klass* get_klass_considering_redefinition(jclass cls, JavaThread* thread) {

src/hotspot/share/prims/jvm.cpp line 2269:

> 2267: }
> 2268: 
> 2269: inline InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread) {

Suggestion:

inline InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread* thread) {

src/hotspot/share/prims/jvmtiThreadState.hpp line 31:

> 29: #include "memory/allocation.hpp"
> 30: #include "oops/oopHandle.hpp"
> 31: #include "oops/instanceKlass.hpp"

Suggestion:

#include "oops/instanceKlass.hpp"
#include "oops/oopHandle.hpp"

Include order is wrong.

src/hotspot/share/prims/jvmtiThreadState.hpp line 438:

> 436:   static inline
> 437:   Klass* class_to_verify_considering_redefinition(Klass* klass,
> 438:                                                   JavaThread *thread) {

Suggestion:

                                                  JavaThread* thread) {

src/hotspot/share/prims/jvmtiThreadState.hpp line 445:

> 443:     } else {
> 444:       return class_to_verify_considering_redefinition(InstanceKlass::cast(klass),
> 445:                                                       thread);

Suggestion:

      return class_to_verify_considering_redefinition(InstanceKlass::cast(klass), thread);

src/hotspot/share/prims/jvmtiThreadState.hpp line 451:

> 449:   static inline
> 450:   InstanceKlass* class_to_verify_considering_redefinition(InstanceKlass* klass,
> 451:                                                           JavaThread *thread) {

Suggestion:

                                                          JavaThread* thread) {

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3227749202
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351033232
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351035033
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351044566
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351048289
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351050636
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351051532

From jsjolen at openjdk.org  Tue Sep 16 07:28:21 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 16 Sep 2025 07:28:21 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two
In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
Message-ID: <QPDIyFgCdAWTMV05IaPJRsLt6eQgJF4dDiUbX-sKnjY=.4a3cbd1e-6ba0-4ca8-875b-319f2f73a75b@github.com>

On Tue, 16 Sep 2025 06:24:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 49:
> 
>> 47: #include "oops/annotations.hpp"
>> 48: #include "oops/constantPool.hpp"
>> 49: #include "oops/constantPool.inline.hpp"
> 
> Suggestion:
> 
> #include "oops/constantPool.inline.hpp"
> 
> You don't include the regular header when you include the inline one.

I wasn't aware! Thanks

> src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 371:
> 
>> 369:   intArray *                  _bsm_index_map_p;
>> 370: 
>> 371:   // After merge_constant_pools pass 0 the BSMAttribute entries of merge_cp_p will have been expanded to fit scratch_cp.
> 
> This comment doesn't read correctly.

There's a missing comma but otherwise it reads fine to me? I added a few more words. There are multiple passes in the method `merge_constant_pools` and they are numbered.


  // After merge_constant_pools pass 0, the BSMAttribute entries of merge_cp_p will have been expanded to fit
  // scratch_cp's BSMAttribute entries as well.
  // However, the newly acquired space will not have been filled in yet.
  // To append to this new space, the iterator is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351203555
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351202052

From jsjolen at openjdk.org  Tue Sep 16 07:33:24 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 16 Sep 2025 07:33:24 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two
In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
Message-ID: <U-M7kjUq4UF4mWYCD9-c8CppgdofSq26AFRc87PDStg=.ba277f2a-0b30-4fdb-8411-f0e087fe9d9d@github.com>

On Tue, 16 Sep 2025 06:22:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 394:
> 
>> 392:   write_attribute_name_index("BootstrapMethods");
>> 393:   u4 length = sizeof(u2) + // num_bootstrap_methods
>> 394:               // The rest of it
> 
> The comment doesn't add any value here.

The previous code did a manual count of the total amount of bytes required. The comment is a bit sloppy, I replaced it with "The rest of the data for the attribute is exactly the u2s in the data array.". The goal is to very explicitly say "we don't need to count, we've got the information already".

> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 398:
> 
>> 396:   write_u4(length);
>> 397: 
>> 398:   int num_bootstrap_methods = cpool()->bsm_entries().number_of_entries();
> 
> I'm confused about the seemingly different uses of `num_bootstrap_methods` here and in the comment above:
> 
> sizeof(u2) + // num_bootstrap_methods
> 
> ?

I'm trying to explain to the reader what the `sizeof(u2)` stands for, in this case it stands for the bytes taken up by the `num_bootstrap_methods` field in `BootstrapMethods_attribute`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351227073
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351221844

From jsjolen at openjdk.org  Tue Sep 16 07:36:28 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 16 Sep 2025 07:36:28 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two
In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
Message-ID: <MHM8yetEY8ddE7P8P4TQKAYfzQiJob5d7Wv1ReH7NOk=.6aedb4eb-69f9-463e-b0a2-6bf4d027fe8e@github.com>

On Tue, 16 Sep 2025 06:15:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Not sure what the indentation rules are for constructors

Same. I added 2 spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351238027

From jsjolen at openjdk.org  Tue Sep 16 08:08:30 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 16 Sep 2025 08:08:30 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two
In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
Message-ID: <Ugg1silaRKumDKiwhjCYDmPjtQHX9y9bvX-GJtnOF0M=.0236fd0f-2560-49c6-971d-1969b64021df@github.com>

On Tue, 16 Sep 2025 06:03:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> src/hotspot/share/oops/constantPool.cpp line 2348:
> 
>> 2346:   assert(num_entries + iter._cur_offset <= iter.insert_into->_offsets->length(), "must");
>> 2347:   for (int i = 0; i < num_entries; i++) {
>> 2348:     const BSMAttributeEntry* bsmae = entry(i);
> 
> Nit: It's okay to use a simple name like `e` to represent `entry` - when you don't have different types of entries involved we don't need to encode the type in the variable name. EDIT: just like in `BSMAttributeEntries::InsertionIterator::reserve_new_entry`.

In this particular case, the `entry` method will be shadowed so you have to explicitly write `this->entry()` if you want to use that name. The existence of that variable is so short, we can just call it `e`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351351291

From fandreuzzi at openjdk.org  Tue Sep 16 08:22:10 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 16 Sep 2025 08:22:10 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
Message-ID: <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>

> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
> 
> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
> 
> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
> 
> I added some files to the ticket for context.
> 
> Passes `tier1` and `tier2`.

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - nn
 - comment and rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27274/files
  - new: https://git.openjdk.org/jdk/pull/27274/files/b839799d..0a5ef012

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

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

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

From jsjolen at openjdk.org  Tue Sep 16 08:47:10 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 16 Sep 2025 08:47:10 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two
In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
Message-ID: <ajD88vsF5SnEj_uApRSFy79MrR8NSsNHLFT9_nfIyi0=.00f89305-2220-44a9-b306-3bbc901c2257@github.com>

On Tue, 16 Sep 2025 06:32:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Overall this looks good - a lot to digest though, so this is only an initial pass (and I'm not that familiar with the existing code).
> 
> Quite a few minor issues (mainly use of `CHECK` macros), some comments and suggestions.
> 
> Thanks

@dholmes-ora, I resolved all of the conversations (and fixed all of the issues). They should still be reachable via "Files Changed" and then "Conversations". If you do continue a conversation in one of the  threads, would you mind pinging me in this main thread? I suspect that Github doesn't send e-mails about convos in resolved threads. Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3296674211

From jsjolen at openjdk.org  Tue Sep 16 09:16:59 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 16 Sep 2025 09:16:59 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v2]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <81ranBcjj7BhSeZC1PvFODRT8j0W8RiNC0rF67pw6To=.e7c62964-a7b8-4ccb-a184-42ad2ea1e3af@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  DHolmes comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/d7c89176..3adc5898

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

  Stats: 42 lines in 7 files changed: 4 ins; 3 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

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

From phubner at openjdk.org  Tue Sep 16 09:35:02 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 09:35:02 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2]
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into JDK-8365858
 - Merge branch 'master' into JDK-8365858
 - Fix typo.
 - Refactor to purely use injected fields.
 - Remove FilteredJavaFieldStream and usages.
 - Remove constantPoolOop from Java code.
 - Make constantPoolOop a hidden vmholder field.

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

Changes: https://git.openjdk.org/jdk/pull/27209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27209&range=01
  Stats: 194 lines in 9 files changed: 9 ins; 166 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/27209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27209/head:pull/27209

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

From phubner at openjdk.org  Tue Sep 16 09:35:03 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 09:35:03 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <Bx6fwP7luYX6eCGcAvgjReYacki2TrQOrSSnXPnDg-k=.9cdea86d-febd-42a3-b9b9-93bd1597a2a4@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <Bx6fwP7luYX6eCGcAvgjReYacki2TrQOrSSnXPnDg-k=.9cdea86d-febd-42a3-b9b9-93bd1597a2a4@github.com>
Message-ID: <vvepwKvbHE8VJFfW_lHJUP6YYem9qZCAW36oICqkbDA=.9f18101f-3801-418c-863a-b41e216c51ce@github.com>

On Mon, 15 Sep 2025 16:00:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all,
>> 
>> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
>> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
>> 2) removes `FilteredJavaFieldStream` entirely, and
>> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
>> 
>> Testing: Oracle tiers 1-3.
>
> ConstantPool in the JVM metadata used to be called constantPoolOop, so I think that's what it's looking to not find.

Thanks for the reviews, @coleenp @liach @jdksjolen @alexmenkov. I've merged in the latest mainline which had a merge commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3297070955

From jsjolen at openjdk.org  Tue Sep 16 10:11:09 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 16 Sep 2025 10:11:09 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v3]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <dHjwBL5Me386yndLZg1UmyP7kfIhJucV624TM0AZdpc=.04350d24-c356-4937-bbf9-c5cb53831059@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Fix type name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/3adc5898..ddf8e8f6

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

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

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

From jsjolen at openjdk.org  Tue Sep 16 12:21:17 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 16 Sep 2025 12:21:17 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2]
In-Reply-To: <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
Message-ID: <8fizZwH_W2n31RiJAJZAxU0dMFs3UaLU0Uk-yoTHST0=.7ab516ac-e506-4635-b08e-f4a3af4cfb7b@github.com>

On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
>> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
>> 2) removes `FilteredJavaFieldStream` entirely, and
>> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
>> 
>> Testing: Oracle tiers 1-3.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into JDK-8365858
>  - Merge branch 'master' into JDK-8365858
>  - Fix typo.
>  - Refactor to purely use injected fields.
>  - Remove FilteredJavaFieldStream and usages.
>  - Remove constantPoolOop from Java code.
>  - Make constantPoolOop a hidden vmholder field.

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3229698749

From erikj at openjdk.org  Tue Sep 16 13:04:16 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 16 Sep 2025 13:04:16 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <w_bendDhRUOHS9-TqRVVwj2ewL3Ye80CAM308VR98qc=.3428049b-bcf7-486a-9046-743ff8829fc3@github.com>

On Sat, 10 May 2025 20:20:32 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

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25167#pullrequestreview-3229887954

From erikj at openjdk.org  Tue Sep 16 13:55:23 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 16 Sep 2025 13:55:23 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <81JqWQPRbafWl22IItWNL52faigZS1l31SXsD9Zq1EE=.b6d84001-edd9-443a-8ca7-555a81ae6af0@github.com>

On Sat, 10 May 2025 20:20:32 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

> /label remove kulla

I have removed kulla-dev from the bot configuration so the stuck label is now benign.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3298796516

From liach at openjdk.org  Tue Sep 16 15:01:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Sep 2025 15:01:24 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2]
In-Reply-To: <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
Message-ID: <u5krOkF_uMpGAxHbdLXKyP4Rz-9YK-qW65UCny5075c=.d7d49d04-3584-4cd3-8f74-430df39e9b31@github.com>

On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
>> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
>> 2) removes `FilteredJavaFieldStream` entirely, and
>> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
>> 
>> Testing: Oracle tiers 1-3.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into JDK-8365858
>  - Merge branch 'master' into JDK-8365858
>  - Fix typo.
>  - Refactor to purely use injected fields.
>  - Remove FilteredJavaFieldStream and usages.
>  - Remove constantPoolOop from Java code.
>  - Make constantPoolOop a hidden vmholder field.

Still looks good

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3230428037

From coleenp at openjdk.org  Tue Sep 16 16:00:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Sep 2025 16:00:22 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition()
In-Reply-To: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
Message-ID: <vEokeRp1ZhM6gzfRwV1rzDNP03UNTsitVBMSWCOaOdc=.cf771262-0c93-4fc4-939a-fe061bc676d5@github.com>

On Tue, 16 Sep 2025 02:44:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.
> 
> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.

This looks good pending David's and my suggested changes (hope it works).
I sort of think there's no need for the Klass* version of get_class_considering_redefinition since its callers seem to really want an InstanceKlass. Since it's jvm.cpp, you can probably verify that it's never Klass in these callers.

src/hotspot/share/prims/jvm.cpp line 2265:

> 2263: inline Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread) {
> 2264:   Klass* k = java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));
> 2265:   k = JvmtiThreadState::class_to_verify_considering_redefinition(k, thread);

Suggestion:

 return JvmtiThreadState::class_to_verify_considering_redefinition(k, thread);

src/hotspot/share/prims/jvm.cpp line 2266:

> 2264:   Klass* k = java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));
> 2265:   k = JvmtiThreadState::class_to_verify_considering_redefinition(k, thread);
> 2266:   return k;

Suggestion:

src/hotspot/share/prims/jvm.cpp line 2271:

> 2269: inline InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread) {
> 2270:   InstanceKlass* ik = java_lang_Class::as_InstanceKlass(JNIHandles::resolve_non_null(cls));
> 2271:   ik = JvmtiThreadState::class_to_verify_considering_redefinition(ik, thread);

Suggestion:

  return JvmtiThreadState::class_to_verify_considering_redefinition(ik, thread);

src/hotspot/share/prims/jvm.cpp line 2272:

> 2270:   InstanceKlass* ik = java_lang_Class::as_InstanceKlass(JNIHandles::resolve_non_null(cls));
> 2271:   ik = JvmtiThreadState::class_to_verify_considering_redefinition(ik, thread);
> 2272:   return ik;

Suggestion:

src/hotspot/share/prims/jvm.cpp line 2291:

> 2289: 
> 2290: JVM_ENTRY(const char*, JVM_GetClassNameUTF(JNIEnv *env, jclass cls))
> 2291:   Klass* k = get_klass_considering_redefinition(cls, thread);

Even if it's a redefined class, it'll have the same name so this isn't necessary.

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

PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3230659598
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352957988
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352958544
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352959692
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352960240
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352970204

From lmesnik at openjdk.org  Tue Sep 16 16:04:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 16:04:56 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked
Message-ID: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>

The
`SuspendResumeManager::suspend(bool register_vthread_SR)`
has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 

Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 

The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

Commit messages:
 - 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked

Changes: https://git.openjdk.org/jdk/pull/27317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367725
  Stats: 50 lines in 5 files changed: 36 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317

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

From phubner at openjdk.org  Tue Sep 16 16:19:13 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 16:19:13 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2]
In-Reply-To: <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
Message-ID: <oxzS7rXgSjMCyoFHisjhdTO-6yYqorBTqkup3YvASk8=.9006018c-1421-4fc9-938c-75706a489de3@github.com>

On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
>> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
>> 2) removes `FilteredJavaFieldStream` entirely, and
>> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
>> 
>> Testing: Oracle tiers 1-3.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into JDK-8365858
>  - Merge branch 'master' into JDK-8365858
>  - Fix typo.
>  - Refactor to purely use injected fields.
>  - Remove FilteredJavaFieldStream and usages.
>  - Remove constantPoolOop from Java code.
>  - Make constantPoolOop a hidden vmholder field.

Thanks for the reviews everyone.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3299475347

From duke at openjdk.org  Tue Sep 16 16:22:21 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Sep 2025 16:22:21 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2]
In-Reply-To: <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
Message-ID: <BvnpINQyRGBopPH2LI7K_81HIBFKAHenFOvcc9NiTNg=.6aa539e6-c22c-4d92-ba88-0795058cef57@github.com>

On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
>> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
>> 2) removes `FilteredJavaFieldStream` entirely, and
>> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
>> 
>> Testing: Oracle tiers 1-3.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into JDK-8365858
>  - Merge branch 'master' into JDK-8365858
>  - Fix typo.
>  - Refactor to purely use injected fields.
>  - Remove FilteredJavaFieldStream and usages.
>  - Remove constantPoolOop from Java code.
>  - Make constantPoolOop a hidden vmholder field.

@Arraying 
Your change (at version 54bc0476fe86c9b1759fff8c0062069ff3e536fa) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3299484854

From lmesnik at openjdk.org  Tue Sep 16 17:57:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 17:57:39 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v2]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <o8OM8PAyMwKW3TxihFp7JhtQh4p0thHQuLb2yGEye9Q=.315d4cec-6dbb-457f-a41a-e3a420a9f686@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  updated test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/5d988b31..3b0b2d76

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

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

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

From lmesnik at openjdk.org  Tue Sep 16 18:08:31 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 18:08:31 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v3]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <CRnMC09-qxc3j6fTTUUgIIYdHZkIaNfESHjnE2sxf1s=.8c772dde-ecc9-4b57-8e40-17faa38a7d03@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  resume tthread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/3b0b2d76..e5743721

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

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

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

From lmesnik at openjdk.org  Tue Sep 16 18:20:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 18:20:13 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v4]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <nmvnMN2C0dPH7NmVQyxRqRXMgIjVp0spq1LfaSc4Msk=.931ff156-f393-4e17-8bf2-aac7ee0db69c@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  typo fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/e5743721..45ff0b72

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

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

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

From fandreuzzi at openjdk.org  Tue Sep 16 18:56:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 16 Sep 2025 18:56:19 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v4]
In-Reply-To: <nmvnMN2C0dPH7NmVQyxRqRXMgIjVp0spq1LfaSc4Msk=.931ff156-f393-4e17-8bf2-aac7ee0db69c@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <nmvnMN2C0dPH7NmVQyxRqRXMgIjVp0spq1LfaSc4Msk=.931ff156-f393-4e17-8bf2-aac7ee0db69c@github.com>
Message-ID: <LRGOEF7NtD6u2ALbmebOOqs5B1Ome6EOx-xXoPE__Lw=.d6921816-6e2b-47c5-8506-7981d70f19bd@github.com>

On Tue, 16 Sep 2025 18:20:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo fixed

src/hotspot/share/runtime/suspendResumeManager.cpp line 92:

> 90:   if (register_vthread_SR) {
> 91:     assert(_target->is_vthread_mounted(), "sanity check");
> 92:       JvmtiVTSuspender::register_vthread_suspend(id);

Suggestion:

    JvmtiVTSuspender::register_vthread_suspend(id);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353373334

From darcy at openjdk.org  Tue Sep 16 19:01:10 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Sep 2025 19:01:10 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <MQk_c-8ME3g7aGxh0gBCqXXKL3vY6yafNuDpG2-xpKM=.e0c950f0-eead-4ebe-a208-3db3e5ef0faa@github.com>

On Sat, 10 May 2025 20:20:32 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

Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3299975129

From lmesnik at openjdk.org  Tue Sep 16 19:11:49 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 19:11:49 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v5]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <pPAz_Fj8hPtvPNl47LcYcFCSc61jYGTk9y4tLkWIMaA=.2d90a599-51df-4702-9713-7ff341b0733a@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  ident fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/45ff0b72..024ff23f

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

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

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

From lmesnik at openjdk.org  Tue Sep 16 19:11:51 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 19:11:51 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v4]
In-Reply-To: <LRGOEF7NtD6u2ALbmebOOqs5B1Ome6EOx-xXoPE__Lw=.d6921816-6e2b-47c5-8506-7981d70f19bd@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <nmvnMN2C0dPH7NmVQyxRqRXMgIjVp0spq1LfaSc4Msk=.931ff156-f393-4e17-8bf2-aac7ee0db69c@github.com>
 <LRGOEF7NtD6u2ALbmebOOqs5B1Ome6EOx-xXoPE__Lw=.d6921816-6e2b-47c5-8506-7981d70f19bd@github.com>
Message-ID: <c0vr0GAJvvut6sGvmR6-xG-RSg56jRb3iChznTVcsDQ=.cef7cdb5-5c4e-47f1-a19b-0c86221ac996@github.com>

On Tue, 16 Sep 2025 18:53:38 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo fixed
>
> src/hotspot/share/runtime/suspendResumeManager.cpp line 92:
> 
>> 90:   if (register_vthread_SR) {
>> 91:     assert(_target->is_vthread_mounted(), "sanity check");
>> 92:       JvmtiVTSuspender::register_vthread_suspend(id);
> 
> Suggestion:
> 
>     JvmtiVTSuspender::register_vthread_suspend(id);

Thanks! Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353404354

From pchilanomate at openjdk.org  Tue Sep 16 19:15:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 16 Sep 2025 19:15:00 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v5]
In-Reply-To: <pPAz_Fj8hPtvPNl47LcYcFCSc61jYGTk9y4tLkWIMaA=.2d90a599-51df-4702-9713-7ff341b0733a@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <pPAz_Fj8hPtvPNl47LcYcFCSc61jYGTk9y4tLkWIMaA=.2d90a599-51df-4702-9713-7ff341b0733a@github.com>
Message-ID: <oDWeTJqyLESWMSpQzrYBl4m4Kuv2DdSZN891me3kdMs=.30e20cc7-03e3-43fd-b802-f897ef7cc68a@github.com>

On Tue, 16 Sep 2025 19:11:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ident fixed

Thanks for finding and fixing this Leonid.

src/hotspot/share/runtime/suspendResumeManager.cpp line 89:

> 87:   int64_t id = java_lang_Thread::thread_id(_target->vthread());
> 88:   ThreadBlockInVM tbivm(current);
> 89:   MutexLocker ml(_state_lock, Mutex::_no_safepoint_check_flag);

Transitioning to the blocked state and acquiring the monitor should still be executed without JVMTI included. We won?t see any issues today because suspend/resume is only used by JVMTI code.

src/hotspot/share/runtime/suspendResumeManager.cpp line 105:

> 103:     // If target is the current thread we can bypass the handshake machinery
> 104:     // and just suspend directly
> 105:     self_suspend(register_vthread_SR, self);

Since `self_suspend()` is a very short method and only called from here, I would keep the method as it was and if anything define `set_suspended_with_id(int64_t id, bool register_vthread_SR)` instead.

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

PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3231325205
PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353407110
PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353410713

From phubner at openjdk.org  Tue Sep 16 19:20:57 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 19:20:57 GMT
Subject: Integrated: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <j-kF5o3qAIVasjK1rctp1y_GKjhUqbVvQpX2Sn2iw6E=.e02e5a9f-ea50-4ea2-80b9-9d9c2d3e37e1@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

This pull request has now been integrated.

Changeset: b75e35cb
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b75e35cb94d17a742d88f23dfd1b016c26a5e63c
Stats:     194 lines in 9 files changed: 9 ins; 166 del; 19 mod

8365858: FilteredJavaFieldStream is unnecessary

Reviewed-by: liach, jsjolen, coleenp, amenkov

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

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

From lmesnik at openjdk.org  Tue Sep 16 19:41:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 19:41:29 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v6]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <nu3L8IokNn4PeQAukNO8MgWTjNdPJzZPUr7SzUkk87U=.3ac3d54c-4b40-4bd6-b850-14c9e9a5b26f@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/024ff23f..0aa24558

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

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

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

From lmesnik at openjdk.org  Tue Sep 16 19:49:19 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 19:49:19 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v7]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <9RYDDTZCCNmLgKRAMyzYIFopSIsm5_zy7S9b_C2YsEc=.39e4bb27-655b-4983-a549-4e050cde6188@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  moved to another method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/0aa24558..d80d7cf4

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

  Stats: 18 lines in 2 files changed: 11 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317

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

From lmesnik at openjdk.org  Tue Sep 16 19:50:38 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 19:50:38 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v5]
In-Reply-To: <oDWeTJqyLESWMSpQzrYBl4m4Kuv2DdSZN891me3kdMs=.30e20cc7-03e3-43fd-b802-f897ef7cc68a@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <pPAz_Fj8hPtvPNl47LcYcFCSc61jYGTk9y4tLkWIMaA=.2d90a599-51df-4702-9713-7ff341b0733a@github.com>
 <oDWeTJqyLESWMSpQzrYBl4m4Kuv2DdSZN891me3kdMs=.30e20cc7-03e3-43fd-b802-f897ef7cc68a@github.com>
Message-ID: <ZYZ5EUsDX_17Mn-ElKgbzvAHXNzUYFcKArTELKLwsTI=.fa20f00b-a9e0-4d5b-a012-64dd916c5b29@github.com>

On Tue, 16 Sep 2025 19:12:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ident fixed
>
> src/hotspot/share/runtime/suspendResumeManager.cpp line 105:
> 
>> 103:     // If target is the current thread we can bypass the handshake machinery
>> 104:     // and just suspend directly
>> 105:     self_suspend(register_vthread_SR, self);
> 
> Since `self_suspend()` is a very short method and only called from here, I would keep the method as it was and if anything define `set_suspended_with_id(int64_t id, bool register_vthread_SR)` instead.

Thanks, moved. Also the include defines become correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353501079

From acobbs at openjdk.org  Tue Sep 16 20:06:30 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 Sep 2025 20:06:30 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <MQk_c-8ME3g7aGxh0gBCqXXKL3vY6yafNuDpG2-xpKM=.e0c950f0-eead-4ebe-a208-3db3e5ef0faa@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <MQk_c-8ME3g7aGxh0gBCqXXKL3vY6yafNuDpG2-xpKM=.e0c950f0-eead-4ebe-a208-3db3e5ef0faa@github.com>
Message-ID: <tpiPsc2LopVOyxCrTiUlPydPgZTXTki_S_fK4WLrnhY=.8989a943-8d89-402e-b2e4-9badfca251ac@github.com>

On Tue, 16 Sep 2025 18:58:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?

Hi @jddarcy,

At the beginning of this project as a preliminary step I filed a bunch of bugs+PR's to remove unnecessary `@SuppressWarnings` annotations. These were accepted, but they affected every area of the JDK and people kept adding new ones so it was impractical to keep up. The only way to make this cleanup operation "stick" is to fail the build whenever anyone violates it, and of course that requires that this PR be integrated first. If/when that happens I plan to do one final "mop up" round that should finally stick :)

Here is the list of earlier clean up PR's:

* #22906
* #21859 
* #21858 
* #21857 
* #21856 
* #21855
* #21854 
* #21853 
* #21852 
* #21851
* #21850 
* #21844

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3300177821

From darcy at openjdk.org  Tue Sep 16 20:17:03 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Sep 2025 20:17:03 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <tpiPsc2LopVOyxCrTiUlPydPgZTXTki_S_fK4WLrnhY=.8989a943-8d89-402e-b2e4-9badfca251ac@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <MQk_c-8ME3g7aGxh0gBCqXXKL3vY6yafNuDpG2-xpKM=.e0c950f0-eead-4ebe-a208-3db3e5ef0faa@github.com>
 <tpiPsc2LopVOyxCrTiUlPydPgZTXTki_S_fK4WLrnhY=.8989a943-8d89-402e-b2e4-9badfca251ac@github.com>
Message-ID: <OfPvRWmG86FOY9SVCOsuEjJKZthp0ML8Eatq2CZnsmg=.2a8ed59f-b5b5-47ec-b70a-8b4d83353342@github.com>

On Tue, 16 Sep 2025 20:03:45 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?
>
>> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?
> 
> Hi @jddarcy,
> 
> At the beginning of this project as a preliminary step I filed a bunch of bugs+PR's to remove unnecessary `@SuppressWarnings` annotations. These were accepted, but they affected every area of the JDK and people kept adding new ones so it was impractical to keep up. The only way to make this cleanup operation "stick" is to fail the build whenever anyone violates it, and of course that requires that this PR be integrated first. If/when that happens I plan to do one final "mop up" round that should finally stick :)
> 
> Here is the list of earlier clean up PR's:
> 
> * #22906
> * #21859 
> * #21858 
> * #21857 
> * #21856 
> * #21855
> * #21854 
> * #21853 
> * #21852 
> * #21851
> * #21850 
> * #21844

> > Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?
> 
> Hi @jddarcy,
> 
> At the beginning of this project as a preliminary step I filed a bunch of bugs+PR's to remove unnecessary `@SuppressWarnings` annotations. These were accepted, but they affected every area of the JDK and people kept adding new ones so it was impractical to keep up. The only way to make this cleanup operation "stick" is to fail the build whenever anyone violates it, and of course that requires that this PR be integrated first. If/when that happens I plan to do one final "mop up" round that should finally stick :)
> 
> Here is the list of earlier clean up PR's:
> 
>     * [8346953: Remove unnecessary @SuppressWarnings annotations (client, #2) #22906](https://github.com/openjdk/jdk/pull/22906)
> 
>     * [8343486: Remove unnecessary @SuppressWarnings annotations and -Xlint:-foo options #21859](https://github.com/openjdk/jdk/pull/21859)
> 
>     * [8343484: Remove unnecessary @SuppressWarnings annotations (nio) #21858](https://github.com/openjdk/jdk/pull/21858)
> 
>     * [8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) #21857](https://github.com/openjdk/jdk/pull/21857)
> 
>     * [8343482: Remove unnecessary @SuppressWarnings annotations (net) #21856](https://github.com/openjdk/jdk/pull/21856)
> 
>     * [8343481: Remove unnecessary @SuppressWarnings annotations (kulla) #21855](https://github.com/openjdk/jdk/pull/21855)
> 
>     * [8343480: Remove unnecessary @SuppressWarnings annotations (javadoc) #21854](https://github.com/openjdk/jdk/pull/21854)
> 
>     * [8343479: Remove unnecessary @SuppressWarnings annotations (hotspot) #21853](https://github.com/openjdk/jdk/pull/21853)
> 
>     * [8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) #21852](https://github.com/openjdk/jdk/pull/21852)
> 
>     * [8343477: Remove unnecessary @SuppressWarnings annotations (compiler) #21851](https://github.com/openjdk/jdk/pull/21851)
> 
>     * [8343476: Remove unnecessary @SuppressWarnings annotations (client) #21850](https://github.com/openjdk/jdk/pull/21850)
> 
>     * [8343467: Remove unnecessary @SuppressWarnings annotations (security) #21844](https://github.com/openjdk/jdk/pull/21844)

Sounds good; I linked the umbrella issue for the earlier round of cleanup to this issue in JBS.

My interest is getting back to at least a subset of modules, including java.base, compiling under "-Xlint:all -Werror" and it sounds like that is the plan as follow-up work after this PR goes in; thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3300210592

From lmesnik at openjdk.org  Tue Sep 16 21:45:37 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Sep 2025 21:45:37 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v8]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <AL5DfzyBI5ujGilavJKIbcNeWdphJdRSwAjsZzV1QCg=.4dc29456-ce48-4482-98fa-9f0fc670b93f@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  test fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/d80d7cf4..0eb9f404

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

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

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

From gennadiy.krivoshein at bell-sw.com  Tue Sep 16 20:41:12 2025
From: gennadiy.krivoshein at bell-sw.com (Gennadiy Krivoshein)
Date: Tue, 16 Sep 2025 20:41:12 +0000
Subject: JDK-8020207, jconsole fails connecting over SSL
Message-ID: <CAKj09HfPG6wVCU5Ew9=+vdMJBgR1dbs0Z1ogFQRAszAvYd2Juw@mail.gmail.com>

Hi serviceability-dev.

I would ask about the JConsole issue JDK-8020207 "jconsole fails connecting
over SSL using service:jmx:rmi://...jndi...",
https://bugs.openjdk.org/browse/JDK-8020207.
This issue was closed with resolutions "Won't fix'. I'm planning to reopen
this issue and start working on it and wanted to check if I'm missing
something before doing so.

The cause of the issue is a connection to the RMI registry. If the registry
and agent use SSLSockets and JConsole is trying to connect to the agent
using "service:jmx:rmi..." URL, ProxyClient of the JConsole does not
attempt to use SSL for communication with the registry, it always tries to
connect using not secured Socket.
A possible solution is to update one of ProxyClient's constructors -
'ProxyClient(String url, String userName, String password)' to check
schemas of the JMX service URL and registry's URL if the schemas are "rmi"
then check the registry's URL path. If the registry's URL path is a well
known "/jmxrmi" then set flag vmConnector to true and check SSL
configuration in the same way as with "host:port".

//// POSSIBLE SOLUTION

private ProxyClient(String url, String userName, String password) throws
IOException {
    this.advancedUrl = url;
    this.connectionName = getConnectionName(url, userName);
    this.displayName = connectionName;
    JMXServiceURL jmxServiceURL = new JMXServiceURL(url);
    if ("rmi".equals(jmxServiceURL.getProtocol())) {
        String path = jmxServiceURL.getURLPath();
        if (path.startsWith("/jndi/")) {
            int end = path.indexOf(';');
            if (end < 0) end = path.length();
            String registryURIStr = path.substring(6, end);
            URI registryURI = URI.create(registryURIStr);
            if ("rmi".equals(registryURI.getScheme())
                    && "/jmxrmi".equals(registryURI.getPath())) {
                this.registryHostName = registryURI.getHost();
                this.registryPort = registryURI.getPort();
                this.vmConnector = true;
                checkSslConfig();
            }
        }
    }
    setParameters(jmxServiceURL, userName, password);
}
//// END OF POSSIBLE SOLUTION

BR, Gennadiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250916/62fd2815/attachment.htm>

From dholmes at openjdk.org  Wed Sep 17 01:01:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 01:01:35 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
In-Reply-To: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
Message-ID: <djEFkH9TKatywyfs8q1S3dT20fPmbHPul8tRiv2jlBg=.db69e134-40d7-4ebe-b3c7-8cce7435d14d@github.com>

On Tue, 16 Sep 2025 03:52:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Goal: simplify AOT implementation and removed unnecessary tests:
> 
> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations).
> 
> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary.
> 
> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production.

Seems like a nice cleanup and simplification.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3232124747

From dholmes at openjdk.org  Wed Sep 17 02:23:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 02:23:35 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v3]
In-Reply-To: <Ugg1silaRKumDKiwhjCYDmPjtQHX9y9bvX-GJtnOF0M=.0236fd0f-2560-49c6-971d-1969b64021df@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
 <Ugg1silaRKumDKiwhjCYDmPjtQHX9y9bvX-GJtnOF0M=.0236fd0f-2560-49c6-971d-1969b64021df@github.com>
Message-ID: <iFC6PZCZ4a83HOWVoTo_QeopavkAeJEA4iHz9dgH2Go=.b06f576e-4a21-4411-8a91-0ceebfe81063@github.com>

On Tue, 16 Sep 2025 08:05:04 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/oops/constantPool.cpp line 2348:
>> 
>>> 2346:   assert(num_entries + iter._cur_offset <= iter.insert_into->_offsets->length(), "must");
>>> 2347:   for (int i = 0; i < num_entries; i++) {
>>> 2348:     const BSMAttributeEntry* bsmae = entry(i);
>> 
>> Nit: It's okay to use a simple name like `e` to represent `entry` - when you don't have different types of entries involved we don't need to encode the type in the variable name. EDIT: just like in `BSMAttributeEntries::InsertionIterator::reserve_new_entry`.
>
> In this particular case, the `entry` method will be shadowed so you have to explicitly write `this->entry()` if you want to use that name. The existence of that variable is so short, we can just call it `e`.

I don't understand your response sorry. I was simply suggesting that `bsmae` could just be `e`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2354074645

From dholmes at openjdk.org  Wed Sep 17 02:33:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 02:33:38 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v3]
In-Reply-To: <dHjwBL5Me386yndLZg1UmyP7kfIhJucV624TM0AZdpc=.04350d24-c356-4937-bbf9-c5cb53831059@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <dHjwBL5Me386yndLZg1UmyP7kfIhJucV624TM0AZdpc=.04350d24-c356-4937-bbf9-c5cb53831059@github.com>
Message-ID: <FSr7olR0HH4WcxJ3Itcbp-RoS_z7bTacv6dls6GsWHM=.6421a41a-c686-43c8-b8ef-53cd93967076@github.com>

On Tue, 16 Sep 2025 10:11:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix type name

Updates look good - thanks. A couple of follow on nits and comments.

Still need to take full second pass through the code.

src/hotspot/share/oops/constantPool.cpp line 1830:

> 1828: bool ConstantPool::compare_bootstrap_entry_to(int idx1, const constantPoolHandle& cp2, int idx2) {
> 1829:   const BSMAttributeEntry* const bsmae1 = bsm_attribute_entry(idx1);
> 1830:   const BSMAttributeEntry* const bsmae2 = cp2->bsm_attribute_entry(idx2);

Suggestion:

  const BSMAttributeEntry* const e1 = bsm_attribute_entry(idx1);
  const BSMAttributeEntry* const e2 = cp2->bsm_attribute_entry(idx2);

Simple names can be used throughout.

src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 371:

> 369:   intArray *                  _bsm_index_map_p;
> 370: 
> 371:   // After merge_constant_pools pass 0, the BSMAttribute entries of merge_cp_p will have been expanded to fit

Suggestion:

  // After merge_constant_pools "Pass 0", the BSMAttribute entries of merge_cp_p will have been expanded to fit

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

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3232321618
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2354096048
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2354103465

From cjplummer at openjdk.org  Wed Sep 17 03:10:43 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Sep 2025 03:10:43 GMT
Subject: RFR: 8367614: Test
 vmTestbase/nsk/jdi/stress/serial/heapwalking001/TestDescription.java failed,
 passed and timed-out
Message-ID: <g_DtE0FusZfxCjs3PoamDiGp22GxArrMiSC1AcAhCP4=.4d0e3627-1d4b-4ca9-9f59-e808050b7c15@github.com>

This test has been silently throwing ObjectCollectedException probably but still passing. I believe it has always done this. The exception went unnoticed because it is caught and then setSuccess(false) is never called. It was finally noticed when this test failed due to a timeout (which seems to be a separate issue), and the ObjectCollectedException was noted in the log.

This PR fixes the setSuccess(false) call in a few places, including in one other test that didn't seem to be otherwise be failing.

The cause of the ObjectCollectedException is a test bug. The test is testing the following:

    // can't force collection of thread group because of 1 reference is always
    // left in parent tread group

So it forces a GC and expects the ObjectReference it has for a ThreadGroup to still be alive. However, the above comment is incorrect. The ThreadGroup spec says:

"A thread group is weakly reachable from its parent group so that it is eligible for garbage collection when there are no live threads in the group and the thread group is otherwise unreachable. "

So this ThreadGroup is being collected, resulting in the ObjectCollectedException in the following code:

            for (ObjectReference objectReference : objectReferences)
                objectReference.referringObjects(0);

This part of the test is invalid and has been removed. I also slightly updated the rest of the test by forcing a gc earlier so we can verify that the ThreadGroup is collected.

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

Commit messages:
 - fix minor typo
 - fix bugs

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

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

From dholmes at openjdk.org  Wed Sep 17 04:09:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 04:09:36 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v8]
In-Reply-To: <AL5DfzyBI5ujGilavJKIbcNeWdphJdRSwAjsZzV1QCg=.4dc29456-ce48-4482-98fa-9f0fc670b93f@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <AL5DfzyBI5ujGilavJKIbcNeWdphJdRSwAjsZzV1QCg=.4dc29456-ce48-4482-98fa-9f0fc670b93f@github.com>
Message-ID: <2xBFWqJ0rGk0NVEygZw2TTetP4WPuQE-KE9fZCDCxl8=.72f5d56e-5899-491f-960f-66579c9fa38b@github.com>

On Tue, 16 Sep 2025 21:45:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fixed

Good find! Always a worry when lack of test coverage is exposed this way.

A couple of suggestions.

Thanks

src/hotspot/share/runtime/suspendResumeManager.cpp line 100:

> 98:     // If target is the current thread we can bypass the handshake machinery
> 99:     // and just suspend directly.
> 100:     // All required data should be loaded before state is set to _thread_blocked.

The comment is a bit vague. Suggestion

// The vthread() oop must only be accessed before state is set to _thread_blocked.

src/hotspot/share/runtime/suspendResumeManager.cpp line 107:

> 105:     do_owner_suspend();
> 106:     return true;
> 107:   }

I prefer to see the `else` remain.

src/hotspot/share/runtime/suspendResumeManager.hpp line 61:

> 59: 
> 60:   void set_suspended(bool to, bool register_vthread_SR);
> 61:   void set_suspended_with_id(int64_t id, bool register_vthread_SR);

Some descriptive comments would be useful now due to the difference in meaning for "suspended". Personally I think we should have `set_suspended` and `set_resumed` rather than passing true/false for the suspend state.

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

PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3232561397
PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2354226780
PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2354227402
PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2354243858

From dholmes at openjdk.org  Wed Sep 17 04:14:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 04:14:31 GMT
Subject: RFR: 8367614: Test
 vmTestbase/nsk/jdi/stress/serial/heapwalking001/TestDescription.java failed,
 passed and timed-out
In-Reply-To: <g_DtE0FusZfxCjs3PoamDiGp22GxArrMiSC1AcAhCP4=.4d0e3627-1d4b-4ca9-9f59-e808050b7c15@github.com>
References: <g_DtE0FusZfxCjs3PoamDiGp22GxArrMiSC1AcAhCP4=.4d0e3627-1d4b-4ca9-9f59-e808050b7c15@github.com>
Message-ID: <xr3l9BXOur25DizXL6-2IQH7ldMAow8Pbz5kTyfcy1Q=.4e55db83-c494-486b-9f9c-a53a8f8a53b8@github.com>

On Wed, 17 Sep 2025 03:03:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test has been silently throwing ObjectCollectedException probably but still passing. I believe it has always done this. The exception went unnoticed because it is caught and then setSuccess(false) is never called. It was finally noticed when this test failed due to a timeout (which seems to be a separate issue), and the ObjectCollectedException was noted in the log.
> 
> This PR fixes the setSuccess(false) call in a few places, including in one other test that didn't seem to be otherwise be failing.
> 
> The cause of the ObjectCollectedException is a test bug. The test is testing the following:
> 
>     // can't force collection of thread group because of 1 reference is always
>     // left in parent tread group
> 
> So it forces a GC and expects the ObjectReference it has for a ThreadGroup to still be alive. However, the above comment is incorrect. The ThreadGroup spec says:
> 
> "A thread group is weakly reachable from its parent group so that it is eligible for garbage collection when there are no live threads in the group and the thread group is otherwise unreachable. "
> 
> So this ThreadGroup is being collected, resulting in the ObjectCollectedException in the following code:
> 
>             for (ObjectReference objectReference : objectReferences)
>                 objectReference.referringObjects(0);
> 
> This part of the test is invalid and has been removed. I also slightly updated the rest of the test by forcing a gc earlier so we can verify that the ThreadGroup is collected.

Seems quite reasonable.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27327#pullrequestreview-3232592556

From jsjolen at openjdk.org  Wed Sep 17 07:26:34 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 17 Sep 2025 07:26:34 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v4]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <_l9gNHqLkkeioUXxWsXpWKp01ft-E06ucp_s5JUPwMo=.1879d0bf-aefd-4912-9ec5-f6d4989396f5@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/prims/jvmtiRedefineClasses.hpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/oops/constantPool.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/ddf8e8f6..0e292522

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

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

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

From ayang at openjdk.org  Wed Sep 17 08:38:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 17 Sep 2025 08:38:01 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
In-Reply-To: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
Message-ID: <qOQe8J3vBFB3NAriObRyOoYqWWXouGpH888w8WKddmA=.1100cb78-f331-44ae-8218-6f2fc706136f@github.com>

On Tue, 16 Sep 2025 03:52:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Goal: simplify AOT implementation and removed unnecessary tests:
> 
> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations).
> 
> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary.
> 
> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3233316083

From kevinw at openjdk.org  Wed Sep 17 11:50:54 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 17 Sep 2025 11:50:54 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
Message-ID: <K7e8UkfKkFbSC0Ljr2lscP-MGJpLnGs4uymyKNl0p4E=.f669c4b5-8399-475a-9487-4715559726d0@github.com>

On Tue, 16 Sep 2025 08:22:10 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - nn
>  - comment and rename

Hi - Do you still have the same core?  Can you attach a "readelf -a " output from it in the jbs issue with the other (helpful) files?  Would like to see how things get mapped.

It's interesting to me at the moment that in a random build of mine with gcc, libjvm has e.g. 

```  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
...
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x00000000022a5a50 0x00000000022a5a50  R E    0x1000
```				 
..so loadable text is just part of the mapping at the base address, no offset.

A core of that contains:

  LOAD           0x000000003431b000 0x00007f1305a15000 0x0000000000000000
                 0x00000000022a6000 0x00000000022a6000  R E    0x1000


But your clang build has the text with some offset and vaddr:
https://bugs.openjdk.org/secure/attachment/116147/libjvm_sections.txt


Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
...
  LOAD           0x000000000067fc80 0x0000000000680c80 0x0000000000680c80
                 0x0000000000e225c0 0x0000000000e225c0  R E    0x1000

..so does that appear as a distinct PH in the core?

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

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3302619729

From mdonovan at openjdk.org  Wed Sep 17 11:58:25 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 17 Sep 2025 11:58:25 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5
 signatures
Message-ID: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>

This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

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

Commit messages:
 - 8353738: Update TLS unit tests to not use certificates with MD5 signatures

Changes: https://git.openjdk.org/jdk/pull/27342/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353738
  Stats: 2551 lines in 10 files changed: 400 ins; 2046 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

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

From lmesnik at openjdk.org  Wed Sep 17 14:56:47 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Sep 2025 14:56:47 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  updated after David's feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/0eb9f404..96dced29

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

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

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

From lmesnik at openjdk.org  Wed Sep 17 14:56:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Sep 2025 14:56:50 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v8]
In-Reply-To: <2xBFWqJ0rGk0NVEygZw2TTetP4WPuQE-KE9fZCDCxl8=.72f5d56e-5899-491f-960f-66579c9fa38b@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <AL5DfzyBI5ujGilavJKIbcNeWdphJdRSwAjsZzV1QCg=.4dc29456-ce48-4482-98fa-9f0fc670b93f@github.com>
 <2xBFWqJ0rGk0NVEygZw2TTetP4WPuQE-KE9fZCDCxl8=.72f5d56e-5899-491f-960f-66579c9fa38b@github.com>
Message-ID: <ff20-dm11__8c2EEZf-LRDfjVBg1tGSXBp6tscl5cAc=.16a4b395-fd15-4e36-aaf2-ff7c7604f232@github.com>

On Wed, 17 Sep 2025 04:05:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test fixed
>
> src/hotspot/share/runtime/suspendResumeManager.hpp line 61:
> 
>> 59: 
>> 60:   void set_suspended(bool to, bool register_vthread_SR);
>> 61:   void set_suspended_with_id(int64_t id, bool register_vthread_SR);
> 
> Some descriptive comments would be useful now due to the difference in meaning for "suspended". Personally I think we should have `set_suspended` and `set_resumed` rather than passing true/false for the suspend state.

I added comment. The set_suspended(bool..) -> set_suspended/set_resumed makes sense since we usually have have suspend/resume pair. I'll look on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2355815267

From sjohanss at openjdk.org  Wed Sep 17 15:13:46 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 17 Sep 2025 15:13:46 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v3]
In-Reply-To: <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
Message-ID: <HrLcTB-gWEdnID7qGySXXe-wbXeZVtC3TrC17oYTz_I=.5ae6ba5f-339f-4e52-875f-ee096d00056e@github.com>

On Fri, 5 Sep 2025 08:33:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to the smaps parser and printer.
>> 
>> **Summary**
>> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
>> 
>> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
>> 
>> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
>> 
>> **Testing**
>> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Offline comments and discussion

Looking for a second reviewer. @tstuefe do you have time to take a closer look.

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

PR Comment: https://git.openjdk.org/jdk/pull/27098#issuecomment-3303467197

From sspitsyn at openjdk.org  Wed Sep 17 19:16:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Sep 2025 19:16:30 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
Message-ID: <U2FDbRT68pxmg9PW_Yw6-tNfqDyx7baSDYf6ZKlJduU=.2cc8add8-2fed-4c16-993a-be6b5db3e9a3@github.com>

On Wed, 17 Sep 2025 14:56:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated after David's feedback

src/hotspot/share/runtime/suspendResumeManager.cpp line 104:

> 102:     ThreadBlockInVM tbivm(self);
> 103:     MutexLocker ml(_state_lock, Mutex::_no_safepoint_check_flag);
> 104:     set_suspended_with_id(id, register_vthread_SR);

Nit: I'd prefer to have the same function name overloaded with a different parameter type.
There can be different opinions here, of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356512510

From lmesnik at openjdk.org  Wed Sep 17 19:24:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Sep 2025 19:24:00 GMT
Subject: RFR: 8367927: Remove 8043571-related tests from problemlists
Message-ID: <pVFKMCWCAY4fMq8rzhu_Uq2wAqPrqKLVnpCFwlJNF8w=.d4d0d8d0-b9cd-4fbf-a424-604cd511844d@github.com>

There are were few fixes in post_method_exit recently. I tried to reproduce this issue and failed.
Let remove tests from problemlist and see if it issue is still reproduced in CI.

The bug https://bugs.openjdk.org/browse/JDK-8043571 remains open so far. It will be closed in jdk26 if not reproduced.

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

Commit messages:
 - 8367927: Remove 8043571-related tests from problemlists

Changes: https://git.openjdk.org/jdk/pull/27351/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27351&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367927
  Stats: 7 lines in 3 files changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27351/head:pull/27351

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

From sspitsyn at openjdk.org  Wed Sep 17 19:48:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Sep 2025 19:48:20 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
Message-ID: <Un5ePQ3MQHRKGDiAOUC_faD4okv8TLrjuEp6c39E6rs=.fa2f594c-50a3-4f4c-931b-500077f41051@github.com>

On Wed, 17 Sep 2025 14:56:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated after David's feedback

I agree with David, it is a good find. Thank you for adding a test coverage and catching it!

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

PR Comment: https://git.openjdk.org/jdk/pull/27317#issuecomment-3304349859

From sspitsyn at openjdk.org  Wed Sep 17 19:51:22 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Sep 2025 19:51:22 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <U2FDbRT68pxmg9PW_Yw6-tNfqDyx7baSDYf6ZKlJduU=.2cc8add8-2fed-4c16-993a-be6b5db3e9a3@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
 <U2FDbRT68pxmg9PW_Yw6-tNfqDyx7baSDYf6ZKlJduU=.2cc8add8-2fed-4c16-993a-be6b5db3e9a3@github.com>
Message-ID: <6jVRMYkRQjvB0q4MlOzqW4MS-0d7NkIplrMJkMKS0Nk=.c9d46ced-f217-41c1-8e52-4f7bf0d446ec@github.com>

On Wed, 17 Sep 2025 19:13:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated after David's feedback
>
> src/hotspot/share/runtime/suspendResumeManager.cpp line 104:
> 
>> 102:     ThreadBlockInVM tbivm(self);
>> 103:     MutexLocker ml(_state_lock, Mutex::_no_safepoint_check_flag);
>> 104:     set_suspended_with_id(id, register_vthread_SR);
> 
> Nit: I'd prefer to have the same function name overloaded with a different parameter type. Then it will be consistent with `JvmtiVTSuspender::register_vthread_suspend(*)` overloaded functions.
> There can be different opinions here, of course.

Renaming it to `self_suspend()` is also a good choice IMHO. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356612043

From fandreuzzi at openjdk.org  Wed Sep 17 20:00:57 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 17 Sep 2025 20:00:57 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <K7e8UkfKkFbSC0Ljr2lscP-MGJpLnGs4uymyKNl0p4E=.f669c4b5-8399-475a-9487-4715559726d0@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
 <K7e8UkfKkFbSC0Ljr2lscP-MGJpLnGs4uymyKNl0p4E=.f669c4b5-8399-475a-9487-4715559726d0@github.com>
Message-ID: <QFMcKMrABiXi-oXNa8LYcnthAulvSIVL5TCZH-HucZI=.804ae591-d101-446b-997d-c895e30efcf7@github.com>

On Wed, 17 Sep 2025 11:48:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - nn
>>  - comment and rename
>
> Hi - Do you still have the same core?  Can you attach a "readelf -a " output from it in the jbs issue with the other (helpful) files?  Would like to see how things get mapped.
> 
> It's interesting to me at the moment that in a random build of mine with gcc, libjvm has e.g. 
> 
> ```  Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
> ...
>   LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
>                  0x00000000022a5a50 0x00000000022a5a50  R E    0x1000
> ```				 
> ..so loadable text is just part of the mapping at the base address, no offset.
> 
> A core of that contains:
> 
>   LOAD           0x000000003431b000 0x00007f1305a15000 0x0000000000000000
>                  0x00000000022a6000 0x00000000022a6000  R E    0x1000
> 
> 
> But your clang build has the text with some offset and vaddr:
> https://bugs.openjdk.org/secure/attachment/116147/libjvm_sections.txt
> 
> 
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
> ...
>   LOAD           0x000000000067fc80 0x0000000000680c80 0x0000000000680c80
>                  0x0000000000e225c0 0x0000000000e225c0  R E    0x1000
> 
> ..so does that appear as a distinct PH in the core?

Hi @kevinjwalls, I don't have the _same_ core. I ran the test another time, you find the new files attached to the ticket (those starting with `2`).

It appears as a distinct program header:

  LOAD           0x0000000006b23000 0x00007fa9ff881000 0x0000000000000000
                 0x0000000000e23000 0x0000000000e23000  R E    0x1000

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

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3304387833

From sspitsyn at openjdk.org  Wed Sep 17 20:09:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Sep 2025 20:09:44 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
In-Reply-To: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
Message-ID: <fRU9HSdG4nufpSG4KIoS1PXkqCNARIEvb14z75To6uY=.54482b16-4a65-4089-9f75-2847cedff364@github.com>

On Tue, 16 Sep 2025 03:52:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Goal: simplify AOT implementation and removed unnecessary tests:
> 
> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations).
> 
> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary.
> 
> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production.

This looks good, nice cleanup.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3236101444

From lmesnik at openjdk.org  Wed Sep 17 20:14:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Sep 2025 20:14:46 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <6jVRMYkRQjvB0q4MlOzqW4MS-0d7NkIplrMJkMKS0Nk=.c9d46ced-f217-41c1-8e52-4f7bf0d446ec@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
 <U2FDbRT68pxmg9PW_Yw6-tNfqDyx7baSDYf6ZKlJduU=.2cc8add8-2fed-4c16-993a-be6b5db3e9a3@github.com>
 <6jVRMYkRQjvB0q4MlOzqW4MS-0d7NkIplrMJkMKS0Nk=.c9d46ced-f217-41c1-8e52-4f7bf0d446ec@github.com>
Message-ID: <U5PzhrNhUHwYWT0MJ3TwnuOyhtJzgfW5uo4Ilke24YY=.de290e3a-56f5-48ad-a472-ee8b36819b98@github.com>

On Wed, 17 Sep 2025 19:48:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/suspendResumeManager.cpp line 104:
>> 
>>> 102:     ThreadBlockInVM tbivm(self);
>>> 103:     MutexLocker ml(_state_lock, Mutex::_no_safepoint_check_flag);
>>> 104:     set_suspended_with_id(id, register_vthread_SR);
>> 
>> Nit: I'd prefer to have the same function name overloaded with a different parameter type. Then it will be consistent with `JvmtiVTSuspender::register_vthread_suspend(*)` overloaded functions.
>> There can be different opinions here, of course.
>
> Renaming it to `self_suspend()` is also a good choice IMHO. :)

The 'self_suspend' is the first attempt, but I agree with @pchilano that it is better to have something similar to
'set_suspended' since the method is doing the same. It not fully suspend but only set status. 
The another possible name that might be:
'set_suspended_current_thread'
to make clear that it is for "self suspension" purpose only.
while the 'with_id' part is clear from the parameters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356664409

From sspitsyn at openjdk.org  Wed Sep 17 20:26:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Sep 2025 20:26:57 GMT
Subject: RFR: 8367614: Test
 vmTestbase/nsk/jdi/stress/serial/heapwalking001/TestDescription.java failed,
 passed and timed-out
In-Reply-To: <g_DtE0FusZfxCjs3PoamDiGp22GxArrMiSC1AcAhCP4=.4d0e3627-1d4b-4ca9-9f59-e808050b7c15@github.com>
References: <g_DtE0FusZfxCjs3PoamDiGp22GxArrMiSC1AcAhCP4=.4d0e3627-1d4b-4ca9-9f59-e808050b7c15@github.com>
Message-ID: <dMxo3OrGWUJm2ol-UAxUH9th015ZoYmQa6xOrVRCYy0=.723e312f-1726-4497-9cbd-829e3c006e3b@github.com>

On Wed, 17 Sep 2025 03:03:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test has been silently throwing ObjectCollectedException probably but still passing. I believe it has always done this. The exception went unnoticed because it is caught and then setSuccess(false) is never called. It was finally noticed when this test failed due to a timeout (which seems to be a separate issue), and the ObjectCollectedException was noted in the log.
> 
> This PR fixes the setSuccess(false) call in a few places, including in one other test that didn't seem to be otherwise be failing.
> 
> The cause of the ObjectCollectedException is a test bug. The test is testing the following:
> 
>     // can't force collection of thread group because of 1 reference is always
>     // left in parent tread group
> 
> So it forces a GC and expects the ObjectReference it has for a ThreadGroup to still be alive. However, the above comment is incorrect. The ThreadGroup spec says:
> 
> "A thread group is weakly reachable from its parent group so that it is eligible for garbage collection when there are no live threads in the group and the thread group is otherwise unreachable. "
> 
> So this ThreadGroup is being collected, resulting in the ObjectCollectedException in the following code:
> 
>             for (ObjectReference objectReference : objectReferences)
>                 objectReference.referringObjects(0);
> 
> This part of the test is invalid and has been removed. I also slightly updated the rest of the test by forcing a gc earlier so we can verify that the ThreadGroup is collected.

Looks good to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27327#pullrequestreview-3236148002

From dholmes at openjdk.org  Wed Sep 17 20:44:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 20:44:47 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <U5PzhrNhUHwYWT0MJ3TwnuOyhtJzgfW5uo4Ilke24YY=.de290e3a-56f5-48ad-a472-ee8b36819b98@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
 <U2FDbRT68pxmg9PW_Yw6-tNfqDyx7baSDYf6ZKlJduU=.2cc8add8-2fed-4c16-993a-be6b5db3e9a3@github.com>
 <6jVRMYkRQjvB0q4MlOzqW4MS-0d7NkIplrMJkMKS0Nk=.c9d46ced-f217-41c1-8e52-4f7bf0d446ec@github.com>
 <U5PzhrNhUHwYWT0MJ3TwnuOyhtJzgfW5uo4Ilke24YY=.de290e3a-56f5-48ad-a472-ee8b36819b98@github.com>
Message-ID: <IEJv_Utpo2Mra_5Kfb171no2V3Ia0wRwPWundDGyHig=.17d52c18-5cf2-4f60-bb51-16525933e133@github.com>

On Wed, 17 Sep 2025 20:11:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Renaming it to `self_suspend()` is also a good choice IMHO. :)
>
> The 'self_suspend' is the first attempt, but I agree with @pchilano that it is better to have something similar to
> 'set_suspended' since the method is doing the same. It not fully suspend but only set status. 
> The another possible name that might be:
> 'set_suspended_current_thread'
> to make clear that it is for "self suspension" purpose only.
> while the 'with_id' part is clear from the parameters.

Given the asymmetry (we don't need a resume path that works with id) I think what you have will do. I just suggest some altered comments below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356729138

From dholmes at openjdk.org  Wed Sep 17 20:44:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 20:44:50 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
Message-ID: <Xqzq7jqNduvtVck23ujf0UteAmrwxGE4tEe-nYe2tNA=.59fb71ce-91a6-4b1a-b92d-65490924568a@github.com>

On Wed, 17 Sep 2025 14:56:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated after David's feedback

src/hotspot/share/runtime/suspendResumeManager.hpp line 63:

> 61: 
> 62:   // The specific 'set_suspended' implementation for self suspend.
> 63:   void set_suspended_with_id(int64_t id, bool register_vthread_SR);

Suggestion:

  // Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true.
  void set_suspended(bool to, bool register_vthread_SR);

  // Sets the suspended state to true, applying to vthreads if `register_vthread_SR` is true.
  // Applied to the thread with the given `id` and used when we can't extract the thread oop safely.
  void set_suspended_with_id(int64_t id, bool register_vthread_SR);

These comments are far from perfect as it is actually hard to explain exactly what `thread` is being operated on - if any!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356737184

From lmesnik at openjdk.org  Wed Sep 17 21:09:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Sep 2025 21:09:29 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <Xqzq7jqNduvtVck23ujf0UteAmrwxGE4tEe-nYe2tNA=.59fb71ce-91a6-4b1a-b92d-65490924568a@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
 <Xqzq7jqNduvtVck23ujf0UteAmrwxGE4tEe-nYe2tNA=.59fb71ce-91a6-4b1a-b92d-65490924568a@github.com>
Message-ID: <z7Urwf_KamM9LP6lD0J7wblSm5FNc5gcpGi79FgxtaE=.f2a5d80e-0743-4945-8952-10da42ebd592@github.com>

On Wed, 17 Sep 2025 20:41:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated after David's feedback
>
> src/hotspot/share/runtime/suspendResumeManager.hpp line 63:
> 
>> 61: 
>> 62:   // The specific 'set_suspended' implementation for self suspend.
>> 63:   void set_suspended_with_id(int64_t id, bool register_vthread_SR);
> 
> Suggestion:
> 
>   // Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true.
>   void set_suspended(bool to, bool register_vthread_SR);
> 
>   // Sets the suspended state to true, applying to vthreads if `register_vthread_SR` is true.
>   // Applied to the thread with the given `id` and used when we can't extract the thread oop safely.
>   void set_suspended_with_id(int64_t id, bool register_vthread_SR);
> 
> These comments are far from perfect as it is actually hard to explain exactly what `thread` is being operated on - if any!

Really the comment 
```// Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true.```
looks incorrect to me. One might decide that the method doesn't set suspend state if for vthreads if `register_vthread_SR` is false. While the method always set suspend and might register or not vthreads to support SuspendAllVirtualThreads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356783702

From lmesnik at openjdk.org  Wed Sep 17 21:23:42 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Sep 2025 21:23:42 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  renamed method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/96dced29..d2587051

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

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

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

From dholmes at openjdk.org  Thu Sep 18 02:44:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 02:44:34 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <z7Urwf_KamM9LP6lD0J7wblSm5FNc5gcpGi79FgxtaE=.f2a5d80e-0743-4945-8952-10da42ebd592@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
 <Xqzq7jqNduvtVck23ujf0UteAmrwxGE4tEe-nYe2tNA=.59fb71ce-91a6-4b1a-b92d-65490924568a@github.com>
 <z7Urwf_KamM9LP6lD0J7wblSm5FNc5gcpGi79FgxtaE=.f2a5d80e-0743-4945-8952-10da42ebd592@github.com>
Message-ID: <ZYZqIo7hl_zEo2wbTsoaGeR4fZIPMHvzIijLD52xCnc=.6011210d-889c-4fa7-8109-e1d78fc5f4d4@github.com>

On Wed, 17 Sep 2025 21:05:26 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/runtime/suspendResumeManager.hpp line 63:
>> 
>>> 61: 
>>> 62:   // The specific 'set_suspended' implementation for self suspend.
>>> 63:   void set_suspended_with_id(int64_t id, bool register_vthread_SR);
>> 
>> Suggestion:
>> 
>>   // Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true.
>>   void set_suspended(bool to, bool register_vthread_SR);
>> 
>>   // Sets the suspended state to true, applying to vthreads if `register_vthread_SR` is true.
>>   // Applied to the thread with the given `id` and used when we can't extract the thread oop safely.
>>   void set_suspended_with_id(int64_t id, bool register_vthread_SR);
>> 
>> These comments are far from perfect as it is actually hard to explain exactly what `thread` is being operated on - if any!
>
> Really the comment 
> ```// Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true.```
> looks incorrect to me. One might decide that the method doesn't set suspend state if for vthreads if `register_vthread_SR` is false. While the method always set suspend and might register or not vthreads to support SuspendAllVirtualThreads.

Okay I was trying to understand exactly what these methods were doing but I'm finding it somewhat difficult to explain that. But my point is to document that the first method sets the state to true/false as directed, whilst the second always sets to true. But it gets harder to describe things when the id variant is only needed when `register_vthread_SR` is true.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357369469

From dholmes at openjdk.org  Thu Sep 18 02:48:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 02:48:45 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
Message-ID: <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com>

On Wed, 17 Sep 2025 21:23:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed method

src/hotspot/share/runtime/suspendResumeManager.cpp line 84:

> 82: }
> 83: 
> 84: void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {

It was totally not at all apparent that `_target` had to be the current thread here! Is it always the current thread? Won't this variant only ever get called when `register_vthread_SR` would be true - in which case we don't need that parameter?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357373281

From dholmes at openjdk.org  Thu Sep 18 02:58:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 02:58:32 GMT
Subject: RFR: 8367927: Remove 8043571-related tests from problemlists
In-Reply-To: <pVFKMCWCAY4fMq8rzhu_Uq2wAqPrqKLVnpCFwlJNF8w=.d4d0d8d0-b9cd-4fbf-a424-604cd511844d@github.com>
References: <pVFKMCWCAY4fMq8rzhu_Uq2wAqPrqKLVnpCFwlJNF8w=.d4d0d8d0-b9cd-4fbf-a424-604cd511844d@github.com>
Message-ID: <UDRc3GQU48X7Ry-7zEOHRpKlsiL7b-io5i9OlFTAbkM=.fa06b0aa-ef52-412f-8ccc-1f878259eb58@github.com>

On Wed, 17 Sep 2025 18:06:21 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are were few fixes in post_method_exit recently. I tried to reproduce this issue and failed.
> Let remove tests from problemlist and see if it issue is still reproduced in CI.
> 
> The bug https://bugs.openjdk.org/browse/JDK-8043571 remains open so far. It will be closed in jdk26 if not reproduced.

I'm a litlle dubious about recent fixes addressing anything related to `-Xcomp` testing, but okay lets try it and see.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27351#pullrequestreview-3237093501

From lmesnik at openjdk.org  Thu Sep 18 03:15:47 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Sep 2025 03:15:47 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
 <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com>
Message-ID: <z6NY7WoFPPTb9H8wUhit7yhZjdk7uRUPqYauY1deD9I=.9543cc97-3c61-4cc9-ac53-4cd2db7f972c@github.com>

On Thu, 18 Sep 2025 02:45:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed method
>
> src/hotspot/share/runtime/suspendResumeManager.cpp line 84:
> 
>> 82: }
>> 83: 
>> 84: void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {
> 
> It was totally not at all apparent that `_target` had to be the current thread here! Is it always the current thread? Won't this variant only ever get called when `register_vthread_SR` would be true - in which case we don't need that parameter?

The `set_suspended_current_thread` is called after check
` if (_target == self) {` in `void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {`
The goal of this specialized method is to "pre-load"`thread_id = _target->vthread()` before current thread became blocked.  It is not planned to use this method for any other purpose.

And the value 'register_vthread_SR'  depends on which jvmti method is used : 
 - true for SuspenAllVirutalThrreads 
 - false for SuspendThread/SuspendThreadList
 In both cases we can try to suspend current thread. So this method is called in both cases, even thread_id is really used only for SuspenAllVirutalThrreads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357403213

From iklam at openjdk.org  Thu Sep 18 03:35:19 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 18 Sep 2025 03:35:19 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
 [v2]
In-Reply-To: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
Message-ID: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com>

> Goal: simplify AOT implementation and removed unnecessary tests:
> 
> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations).
> 
> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary.
> 
> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into 8362561-remove-diagnostic-option-AllowArchivingWithJavaAgent
 - Added test case for dynamic archive with -javaagent
 - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent

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

Changes: https://git.openjdk.org/jdk/pull/27304/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27304&range=01
  Stats: 1197 lines in 25 files changed: 41 ins; 1146 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27304.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27304/head:pull/27304

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

From dholmes at openjdk.org  Thu Sep 18 04:45:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 04:45:33 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <z6NY7WoFPPTb9H8wUhit7yhZjdk7uRUPqYauY1deD9I=.9543cc97-3c61-4cc9-ac53-4cd2db7f972c@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
 <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com>
 <z6NY7WoFPPTb9H8wUhit7yhZjdk7uRUPqYauY1deD9I=.9543cc97-3c61-4cc9-ac53-4cd2db7f972c@github.com>
Message-ID: <eAxIjtOV2yzv-euRGt3acoGNHp2jwyXjduyBXZ9WUf4=.29a6c60a-15fc-428b-ac38-ae8e40e2cffd@github.com>

On Thu, 18 Sep 2025 03:13:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/runtime/suspendResumeManager.cpp line 84:
>> 
>>> 82: }
>>> 83: 
>>> 84: void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {
>> 
>> It was totally not at all apparent that `_target` had to be the current thread here! Is it always the current thread? Won't this variant only ever get called when `register_vthread_SR` would be true - in which case we don't need that parameter?
>
> Yes, the purpose of this specialized method is to "pre-load"`thread_id = _target->vthread()` before current thread became blocked.    It is not planned to use this method for any other purpose.
> The `set_suspended_current_thread` is called after check
> ` if (_target == self) {` in `void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {`
> 
> 
> And the value 'register_vthread_SR'  doesn't correlate with this method. It depends on which jvmti method is used : 
>  - true for SuspenAllVirutalThrreads 
>  - false for SuspendThread/SuspendThreadList
>  In both cases we can try to suspend current thread. So this method is called in both cases, even thread_id is really used only for SuspenAllVirutalThrreads.
> 
> Hope it makes clearer.

Thanks - though I find this code rather convoluted. We now always extract the `id` even though we only need it in the `register_vthread_SR == true` case. I tried different re-arrangements of the code to see if it could be cleaner, but the JVMTI part is just messy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357499435

From dholmes at openjdk.org  Thu Sep 18 04:45:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 04:45:36 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
Message-ID: <DOCN5UKV-7OIQowlx-OpfHFaWgDBFqHycwdDybv0EO4=.c5648ca9-3409-4729-a018-62e539637881@github.com>

On Wed, 17 Sep 2025 21:23:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed method

src/hotspot/share/runtime/suspendResumeManager.cpp line 88:

> 86:   if (register_vthread_SR) {
> 87:     assert(_target->is_vthread_mounted(), "sanity check");
> 88:     assert(_target == JavaThread::current(), "should be current thread");

So this assert should be outside the INCLUDE_JVMTI section - right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357499917

From iklam at openjdk.org  Thu Sep 18 04:46:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 18 Sep 2025 04:46:33 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
 [v2]
In-Reply-To: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
 <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com>
Message-ID: <A5l4-dRX7GwoehmiFGC4Dks3mQhISh3McAu1Nirp_AE=.b061c45d-c73e-4e47-a3dd-52f217ef0de1@github.com>

On Thu, 18 Sep 2025 03:35:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Goal: simplify AOT implementation and removed unnecessary tests:
>> 
>> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations).
>> 
>> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary.
>> 
>> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into 8362561-remove-diagnostic-option-AllowArchivingWithJavaAgent
>  - Added test case for dynamic archive with -javaagent
>  - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent

I have merged manually to fix conflicts in TEST.groups. No other changes.
Please re-review. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27304#issuecomment-3305406551

From lmesnik at openjdk.org  Thu Sep 18 04:52:32 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Sep 2025 04:52:32 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <eAxIjtOV2yzv-euRGt3acoGNHp2jwyXjduyBXZ9WUf4=.29a6c60a-15fc-428b-ac38-ae8e40e2cffd@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
 <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com>
 <z6NY7WoFPPTb9H8wUhit7yhZjdk7uRUPqYauY1deD9I=.9543cc97-3c61-4cc9-ac53-4cd2db7f972c@github.com>
 <eAxIjtOV2yzv-euRGt3acoGNHp2jwyXjduyBXZ9WUf4=.29a6c60a-15fc-428b-ac38-ae8e40e2cffd@github.com>
Message-ID: <CrWtZUxBlwr5WopUUWrwdXDSF1DNrjO1WE2gN308L3Q=.90153219-5098-4ad5-8796-8e1d20dfe090@github.com>

On Thu, 18 Sep 2025 04:42:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes, the purpose of this specialized method is to "pre-load"`thread_id = _target->vthread()` before current thread became blocked.    It is not planned to use this method for any other purpose.
>> The `set_suspended_current_thread` is called after check
>> ` if (_target == self) {` in `void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {`
>> 
>> 
>> And the value 'register_vthread_SR'  doesn't correlate with this method. It depends on which jvmti method is used : 
>>  - true for SuspenAllVirutalThrreads 
>>  - false for SuspendThread/SuspendThreadList
>>  In both cases we can try to suspend current thread. So this method is called in both cases, even thread_id is really used only for SuspenAllVirutalThrreads.
>> 
>> Hope it makes clearer.
>
> Thanks - though I find this code rather convoluted. We now always extract the `id` even though we only need it in the `register_vthread_SR == true` case. I tried different re-arrangements of the code to see if it could be cleaner, but the JVMTI part is just messy.

Yes, the id is always extracted and the exposure of "raw" id on this level is not the good desing. However, I don't know how to implement this better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357508462

From lmesnik at openjdk.org  Thu Sep 18 05:12:14 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Sep 2025 05:12:14 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v11]
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <qj_yqYpR1zm9eqNvkX4JB4Hz-CDZtWlD3EBPJUEN8MY=.b16fbed1-2c11-4725-b614-8bf3b66b98c8@github.com>

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

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

  asseriton moved out

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27317/files
  - new: https://git.openjdk.org/jdk/pull/27317/files/d2587051..63392d0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=09-10

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

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

From lmesnik at openjdk.org  Thu Sep 18 05:12:16 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Sep 2025 05:12:16 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <DOCN5UKV-7OIQowlx-OpfHFaWgDBFqHycwdDybv0EO4=.c5648ca9-3409-4729-a018-62e539637881@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
 <DOCN5UKV-7OIQowlx-OpfHFaWgDBFqHycwdDybv0EO4=.c5648ca9-3409-4729-a018-62e539637881@github.com>
Message-ID: <UplqsUjC3p9h5KLSmYspLxDh23ZtyeKvh0HiM-DEcDE=.0e60569c-e3b2-4267-a780-e07df516996a@github.com>

On Thu, 18 Sep 2025 04:42:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed method
>
> src/hotspot/share/runtime/suspendResumeManager.cpp line 88:
> 
>> 86:   if (register_vthread_SR) {
>> 87:     assert(_target->is_vthread_mounted(), "sanity check");
>> 88:     assert(_target == JavaThread::current(), "should be current thread");
> 
> So this assert should be outside the INCLUDE_JVMTI section - right?

ough,
yes, should be outside INCLUDE_JVMTI 
However, I just can't understand how those methods could be called if JVMTI is not included. Do we still have any mechanisms to suspend thread without jvmti nowdays?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357528204

From lmesnik at openjdk.org  Thu Sep 18 05:16:33 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Sep 2025 05:16:33 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v9]
In-Reply-To: <ZYZqIo7hl_zEo2wbTsoaGeR4fZIPMHvzIijLD52xCnc=.6011210d-889c-4fa7-8109-e1d78fc5f4d4@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <OiC0vQdf7ltwN59jigaycTJtKamweNrDobvRtt-jFGo=.03236ddc-bbee-4ff8-904d-0e15cca57ac7@github.com>
 <Xqzq7jqNduvtVck23ujf0UteAmrwxGE4tEe-nYe2tNA=.59fb71ce-91a6-4b1a-b92d-65490924568a@github.com>
 <z7Urwf_KamM9LP6lD0J7wblSm5FNc5gcpGi79FgxtaE=.f2a5d80e-0743-4945-8952-10da42ebd592@github.com>
 <ZYZqIo7hl_zEo2wbTsoaGeR4fZIPMHvzIijLD52xCnc=.6011210d-889c-4fa7-8109-e1d78fc5f4d4@github.com>
Message-ID: <YVu0gDCJ-KSZAJWarh3lZ4fnxnWDu_x0oXab12qDbS0=.ccc06214-9627-47f0-bc15-a3a7a130f5de@github.com>

On Thu, 18 Sep 2025 02:42:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Really the comment 
>> ```// Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true.```
>> looks incorrect to me. One might decide that the method doesn't set suspend state if for vthreads if `register_vthread_SR` is false. While the method always set suspend and might register or not vthreads to support SuspendAllVirtualThreads.
>
> Okay I was trying to understand exactly what these methods were doing but I'm finding it somewhat difficult to explain that. But my point is to document that the first method sets the state to true/false as directed, whilst the second always sets to true. But it gets harder to describe things when the id variant is only needed when `register_vthread_SR` is true.

The `set_suspended` maintained _suspended flag for individual flags. While to support fast suspending of all virtual threads it uses additional mechanisms.
So, it is rather `set_suspended_status` or something like this. 
I don't know what would be good name for this logic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357537396

From dholmes at openjdk.org  Thu Sep 18 05:44:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 05:44:33 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <UplqsUjC3p9h5KLSmYspLxDh23ZtyeKvh0HiM-DEcDE=.0e60569c-e3b2-4267-a780-e07df516996a@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
 <DOCN5UKV-7OIQowlx-OpfHFaWgDBFqHycwdDybv0EO4=.c5648ca9-3409-4729-a018-62e539637881@github.com>
 <UplqsUjC3p9h5KLSmYspLxDh23ZtyeKvh0HiM-DEcDE=.0e60569c-e3b2-4267-a780-e07df516996a@github.com>
Message-ID: <B2AqeTDAh4xeH2i7piWiHyUQgeap4-C1tC2BIoV8Bp8=.24798e27-1d81-4b74-88cf-aa76b072c9a7@github.com>

On Thu, 18 Sep 2025 05:07:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/runtime/suspendResumeManager.cpp line 88:
>> 
>>> 86:   if (register_vthread_SR) {
>>> 87:     assert(_target->is_vthread_mounted(), "sanity check");
>>> 88:     assert(_target == JavaThread::current(), "should be current thread");
>> 
>> So this assert should be outside the INCLUDE_JVMTI section - right?
>
> ough,
> yes, should be outside INCLUDE_JVMTI 
> However, I just can't understand how those methods could be called if JVMTI is not included. Do we still have any mechanisms to suspend thread without jvmti nowdays?

No we don't but we are left with a lot of historical code organization. JVMTI is the only client of the `JavaThread::java_suspend/java_resume` API but that code already existed independent of JVMTI. The current INCLUDE_JVMTI guards are what is needed to make a non-JVMTI configuration build. If we were so inclined we could push those guards right up to JavaThread and then exclude compiling files like `suspendResumeManager.cpp`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357574737

From dholmes at openjdk.org  Thu Sep 18 06:16:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 06:16:33 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <B2AqeTDAh4xeH2i7piWiHyUQgeap4-C1tC2BIoV8Bp8=.24798e27-1d81-4b74-88cf-aa76b072c9a7@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
 <DOCN5UKV-7OIQowlx-OpfHFaWgDBFqHycwdDybv0EO4=.c5648ca9-3409-4729-a018-62e539637881@github.com>
 <UplqsUjC3p9h5KLSmYspLxDh23ZtyeKvh0HiM-DEcDE=.0e60569c-e3b2-4267-a780-e07df516996a@github.com>
 <B2AqeTDAh4xeH2i7piWiHyUQgeap4-C1tC2BIoV8Bp8=.24798e27-1d81-4b74-88cf-aa76b072c9a7@github.com>
Message-ID: <tV5cZZJ3bZ1Q4vRNHFaUgTRK6akq-v8wjvbM0p6lNis=.b39acd44-e9e3-479c-ab04-b448f1061f02@github.com>

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

>> ough,
>> yes, should be outside INCLUDE_JVMTI 
>> However, I just can't understand how those methods could be called if JVMTI is not included. Do we still have any mechanisms to suspend thread without jvmti nowdays?
>
> No we don't but we are left with a lot of historical code organization. JVMTI is the only client of the `JavaThread::java_suspend/java_resume` API but that code already existed independent of JVMTI. The current INCLUDE_JVMTI guards are what is needed to make a non-JVMTI configuration build. If we were so inclined we could push those guards right up to JavaThread and then exclude compiling files like `suspendResumeManager.cpp`.

Except the notion of "suspend" permeates the handshake code and is impossible to disentangle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357624527

From mbaesken at openjdk.org  Thu Sep 18 07:33:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 18 Sep 2025 07:33:09 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
Message-ID: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>

A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

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

Commit messages:
 - JDK-8367913

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

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

From jsjolen at openjdk.org  Thu Sep 18 07:41:31 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 18 Sep 2025 07:41:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Fix rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/0e292522..6f47508b

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

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

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

From shade at openjdk.org  Thu Sep 18 07:51:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 18 Sep 2025 07:51:23 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
 [v2]
In-Reply-To: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
 <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com>
Message-ID: <wGoDgLyC2PV9rJKFeBkJFdqye8Gsh68rHK4Apsf7Rj8=.4d8e7922-7fd0-4e05-9d2e-861c45867984@github.com>

On Thu, 18 Sep 2025 03:35:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Goal: simplify AOT implementation and removed unnecessary tests:
>> 
>> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations).
>> 
>> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary.
>> 
>> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into 8362561-remove-diagnostic-option-AllowArchivingWithJavaAgent
>  - Added test case for dynamic archive with -javaagent
>  - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent

Looks reasonable.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3237906570

From kevinw at openjdk.org  Thu Sep 18 10:29:30 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 18 Sep 2025 10:29:30 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
Message-ID: <_ibjzLZnC5NGYTnyawKsgT2ZMwEF1WyDqYH_tycmYL4=.dca3377a-eaf2-4b8f-b140-818e19a994cd@github.com>

On Tue, 16 Sep 2025 08:22:10 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - nn
>  - comment and rename

Thanks - does that still have the same problem?
(Do you have the jtreg log from this one, to confirm I was looking at the right address here...)


libjvm second seg:
core:

Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000006b23000 0x00007fa9ff881000 0x0000000000000000
                 0x0000000000e23000 0x0000000000e23000  R E    0x1000


libjvm binary:

LOAD           0x0000000000680180 0x0000000000681180 0x0000000000681180
               0x0000000000e226c0 0x0000000000e226c0  R E    0x1000

			 
These figures look like they work, for that check which has been working for gcc builds:

ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size)

left: 	core file memsize: 0x0000000000e23000
right: 	lib mem size 0x0000000000e226c0 rounds to 0xe23000
	
Was core 1 different? Looks like a slightly smaller libjvm in that run (mem size was 0e225c0 and the core contained a 0xe24000 size mapping, which was the problem).

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

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3306693613

From kevinw at openjdk.org  Thu Sep 18 12:17:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 18 Sep 2025 12:17:56 GMT
Subject: RFR: 8367983: javax/management/monitor/ThreadPoolTest.java and
 StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!
Message-ID: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>

This test has failed due to a timing issue, but not continually or reproducibly.
Looks like an effect of the TIMEOUT_FACTOR change (8260555).

The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0

We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.ack a few years, so multiply the current 500ms by a little more than 4.

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

Commit messages:
 - 8038950: javax/management/monitor/ThreadPoolTest.java and StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!

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

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

From clanger at openjdk.org  Thu Sep 18 12:55:14 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 18 Sep 2025 12:55:14 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <OB2a9gQR4TnW2g9jtSczijMfOY3qU6CTq6C5rpWMklI=.a71a921d-cd45-4f5a-bd72-ed38d01b064c@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

Code changes look good but I guess somebody from Oracle has to verify this, whether it does not break unwanted things.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3239492738

From mdoerr at openjdk.org  Thu Sep 18 13:03:20 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 18 Sep 2025 13:03:20 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <tvYCS02M14QNXmqLjLSB6bra7GT6BM4a7wNc9_HHWwI=.fa4022a3-4c51-4334-964d-74d174f34cf2@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

+1

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3239571890

From erikj at openjdk.org  Thu Sep 18 13:15:40 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Sep 2025 13:15:40 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

I have started a verification job with tier1-5.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3307387278

From mbaesken at openjdk.org  Thu Sep 18 13:40:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 18 Sep 2025 13:40:13 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
Message-ID: <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>

On Thu, 18 Sep 2025 13:13:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I have started a verification job with tier1-5.

Hi Erik, thanks for checking !

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3307512079

From stuefe at openjdk.org  Thu Sep 18 14:13:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 Sep 2025 14:13:49 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v3]
In-Reply-To: <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
Message-ID: <VAFf37NxFDZ6k79sUVNCnLXYyKsiZFTauqjhRQtsb-g=.8bc8b23d-3fd0-4e52-bd5f-04225cdcfae2@github.com>

On Fri, 5 Sep 2025 08:33:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to the smaps parser and printer.
>> 
>> **Summary**
>> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
>> 
>> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
>> 
>> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
>> 
>> **Testing**
>> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Offline comments and discussion

Sorry for the delay, I was missing this one.

Good. Small nits inside, up to you if you take the suggestions. I don't need another review.

src/hotspot/os/linux/procMapsParser.cpp line 83:

> 81:   // scan THPeligible into a bool
> 82:   int thpel = 0;
> 83:   if (::sscanf(_line, "THPeligible: %d", &thpel) == 1) {

Suggestion:

  if (::sscanf(_line, "THPeligible: %d", &thpel) == 1) {
    assert(thpel == 1 || thpel == 0, "Unexpected value %d", thpel);

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java line 102:

> 100:             // metaspace
> 101:             regexBase_committed + "META.*",
> 102:             // parts of metaspace should be uncommitted, those parts can be thp eligible

Suggestion:

            // parts of metaspace should be uncommitted, those parts may or may not be be thp-eligible

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27098#pullrequestreview-3240000359
PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2359510679
PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2359515522

From sspitsyn at openjdk.org  Thu Sep 18 14:31:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 18 Sep 2025 14:31:46 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
 [v2]
In-Reply-To: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
 <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com>
Message-ID: <PyuGAP-z173AyTQFdWISQHau1uC1ho4NSnx4V0GQP6Y=.f18ffc23-5620-4a76-9a61-93b63950766c@github.com>

On Thu, 18 Sep 2025 03:35:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Goal: simplify AOT implementation and removed unnecessary tests:
>> 
>> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations).
>> 
>> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary.
>> 
>> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into 8362561-remove-diagnostic-option-AllowArchivingWithJavaAgent
>  - Added test case for dynamic archive with -javaagent
>  - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3240125838

From sspitsyn at openjdk.org  Thu Sep 18 14:31:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 18 Sep 2025 14:31:48 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
 [v2]
In-Reply-To: <A5l4-dRX7GwoehmiFGC4Dks3mQhISh3McAu1Nirp_AE=.b061c45d-c73e-4e47-a3dd-52f217ef0de1@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
 <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com>
 <A5l4-dRX7GwoehmiFGC4Dks3mQhISh3McAu1Nirp_AE=.b061c45d-c73e-4e47-a3dd-52f217ef0de1@github.com>
Message-ID: <1WUA7IO4VV9v2g94V8V_kXLO5-MwySbuTwGx0aM7Tlw=.1032ac3a-6004-48f1-bce3-7b0264c4e7d7@github.com>

On Thu, 18 Sep 2025 04:43:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I have merged manually to fix conflicts in TEST.groups. No other changes.
> Please re-review. Thanks!

It looks okay but I've noticed that now 9 lines are removed in TEST.groups instead of 10. I hope it is intentional.

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

PR Comment: https://git.openjdk.org/jdk/pull/27304#issuecomment-3307782824

From ihse at openjdk.org  Thu Sep 18 14:38:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Sep 2025 14:38:19 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

make/modules/java.base/Lib.gmk line 165:

> 163:     LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
> 164:     LDFLAGS_aix := -brtl -bexpfull, \
> 165:     LIBS_linux := $(LIBDL) $(LIBM), \

I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2359642913

From ihse at openjdk.org  Thu Sep 18 14:50:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Sep 2025 14:50:18 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <MVyErx68K01TNoNDTJ3-UlvD-52jsHEZUzxQyw_sK4I=.63b6341d-78d0-40a9-80f4-eb589fd7726b@github.com>

On Sat, 10 May 2025 20:20:32 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

Build changes look fine.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25167#pullrequestreview-3240239228

From cjplummer at openjdk.org  Thu Sep 18 15:35:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Sep 2025 15:35:53 GMT
Subject: RFR: 8367614: Test
 vmTestbase/nsk/jdi/stress/serial/heapwalking001/TestDescription.java failed,
 passed and timed-out
In-Reply-To: <g_DtE0FusZfxCjs3PoamDiGp22GxArrMiSC1AcAhCP4=.4d0e3627-1d4b-4ca9-9f59-e808050b7c15@github.com>
References: <g_DtE0FusZfxCjs3PoamDiGp22GxArrMiSC1AcAhCP4=.4d0e3627-1d4b-4ca9-9f59-e808050b7c15@github.com>
Message-ID: <VJQYcvkdygamz2hkT4krJM-A9phgJuQqGhqL9lQT1DA=.6839ac24-d746-470a-8f56-e37bfde30e5d@github.com>

On Wed, 17 Sep 2025 03:03:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test has been silently throwing ObjectCollectedException probably but still passing. I believe it has always done this. The exception went unnoticed because it is caught and then setSuccess(false) is never called. It was finally noticed when this test failed due to a timeout (which seems to be a separate issue), and the ObjectCollectedException was noted in the log.
> 
> This PR fixes the setSuccess(false) call in a few places, including in one other test that didn't seem to be otherwise be failing.
> 
> The cause of the ObjectCollectedException is a test bug. The test is testing the following:
> 
>     // can't force collection of thread group because of 1 reference is always
>     // left in parent tread group
> 
> So it forces a GC and expects the ObjectReference it has for a ThreadGroup to still be alive. However, the above comment is incorrect. The ThreadGroup spec says:
> 
> "A thread group is weakly reachable from its parent group so that it is eligible for garbage collection when there are no live threads in the group and the thread group is otherwise unreachable. "
> 
> So this ThreadGroup is being collected, resulting in the ObjectCollectedException in the following code:
> 
>             for (ObjectReference objectReference : objectReferences)
>                 objectReference.referringObjects(0);
> 
> This part of the test is invalid and has been removed. I also slightly updated the rest of the test by forcing a gc earlier so we can verify that the ThreadGroup is collected.

Thank you for the reviews Serguei and David!

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

PR Comment: https://git.openjdk.org/jdk/pull/27327#issuecomment-3308155863

From cjplummer at openjdk.org  Thu Sep 18 15:36:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Sep 2025 15:36:52 GMT
Subject: RFR: 8367983: javax/management/monitor/ThreadPoolTest.java and
 StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!
In-Reply-To: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
References: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
Message-ID: <sXZxIEqDUhJAPQomtJpUv2c7ntsK8_AVWmOnWqLjE8o=.e3a44ad0-f949-442e-9c0a-f85281509e0b@github.com>

On Thu, 18 Sep 2025 11:47:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has failed due to a timing issue, but not continually or reproducibly.
> Looks like an effect of the TIMEOUT_FACTOR change (8260555).
> 
> The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0
> 
> We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.ack a few years, so multiply the current 500ms by a little more than 4.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27361#pullrequestreview-3240527778

From cjplummer at openjdk.org  Thu Sep 18 15:39:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Sep 2025 15:39:05 GMT
Subject: Integrated: 8367614: Test
 vmTestbase/nsk/jdi/stress/serial/heapwalking001/TestDescription.java failed,
 passed and timed-out
In-Reply-To: <g_DtE0FusZfxCjs3PoamDiGp22GxArrMiSC1AcAhCP4=.4d0e3627-1d4b-4ca9-9f59-e808050b7c15@github.com>
References: <g_DtE0FusZfxCjs3PoamDiGp22GxArrMiSC1AcAhCP4=.4d0e3627-1d4b-4ca9-9f59-e808050b7c15@github.com>
Message-ID: <Hc6MlftGKCSKg2zVPyY7sI5sRyxrl93yAPh18tGFBRY=.3aae5baf-371c-4372-9d83-e293cb5d2674@github.com>

On Wed, 17 Sep 2025 03:03:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test has been silently throwing ObjectCollectedException probably but still passing. I believe it has always done this. The exception went unnoticed because it is caught and then setSuccess(false) is never called. It was finally noticed when this test failed due to a timeout (which seems to be a separate issue), and the ObjectCollectedException was noted in the log.
> 
> This PR fixes the setSuccess(false) call in a few places, including in one other test that didn't seem to be otherwise be failing.
> 
> The cause of the ObjectCollectedException is a test bug. The test is testing the following:
> 
>     // can't force collection of thread group because of 1 reference is always
>     // left in parent tread group
> 
> So it forces a GC and expects the ObjectReference it has for a ThreadGroup to still be alive. However, the above comment is incorrect. The ThreadGroup spec says:
> 
> "A thread group is weakly reachable from its parent group so that it is eligible for garbage collection when there are no live threads in the group and the thread group is otherwise unreachable. "
> 
> So this ThreadGroup is being collected, resulting in the ObjectCollectedException in the following code:
> 
>             for (ObjectReference objectReference : objectReferences)
>                 objectReference.referringObjects(0);
> 
> This part of the test is invalid and has been removed. I also slightly updated the rest of the test by forcing a gc earlier so we can verify that the ThreadGroup is collected.

This pull request has now been integrated.

Changeset: b8f2c738
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8f2c7387f4b5a60a6b671619d968d1d77aa9c27
Stats:     57 lines in 2 files changed: 12 ins; 34 del; 11 mod

8367614: Test vmTestbase/nsk/jdi/stress/serial/heapwalking001/TestDescription.java failed, passed and timed-out

Reviewed-by: dholmes, sspitsyn

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

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

From pchilanomate at openjdk.org  Thu Sep 18 15:58:57 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 18 Sep 2025 15:58:57 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v11]
In-Reply-To: <qj_yqYpR1zm9eqNvkX4JB4Hz-CDZtWlD3EBPJUEN8MY=.b16fbed1-2c11-4725-b614-8bf3b66b98c8@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <qj_yqYpR1zm9eqNvkX4JB4Hz-CDZtWlD3EBPJUEN8MY=.b16fbed1-2c11-4725-b614-8bf3b66b98c8@github.com>
Message-ID: <JjRmUvsrJEVzAaMxJ9gAVDiOh_-ehrMDGksYcPRfZaI=.78265911-2f7d-40bc-862e-645ba7523279@github.com>

On Thu, 18 Sep 2025 05:12:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   asseriton moved out

Current version looks good to me, thanks.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3240659049

From iklam at openjdk.org  Thu Sep 18 16:12:19 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 18 Sep 2025 16:12:19 GMT
Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent
 [v2]
In-Reply-To: <1WUA7IO4VV9v2g94V8V_kXLO5-MwySbuTwGx0aM7Tlw=.1032ac3a-6004-48f1-bce3-7b0264c4e7d7@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
 <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com>
 <A5l4-dRX7GwoehmiFGC4Dks3mQhISh3McAu1Nirp_AE=.b061c45d-c73e-4e47-a3dd-52f217ef0de1@github.com>
 <1WUA7IO4VV9v2g94V8V_kXLO5-MwySbuTwGx0aM7Tlw=.1032ac3a-6004-48f1-bce3-7b0264c4e7d7@github.com>
Message-ID: <b5KHfOhYFceYBZzkl5EgkzqY6zvQqowBpqKwAszwAZE=.c12dee98-aae7-42f3-a9b7-0f2b4a80666b@github.com>

On Thu, 18 Sep 2025 14:29:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > I have merged manually to fix conflicts in TEST.groups. No other changes.
> > Please re-review. Thanks!
> 
> It looks okay but I've noticed that now 9 lines are removed in TEST.groups instead of 10. I hope it is intentional.

Yes, it's intentional. Some of those lines were already removed by another recent [changeset 91a979430e2516b5853c397a336837799928f478](https://github.com/openjdk/jdk/commit/91a979430e2516b5853c397a336837799928f478#diff-6a6d33f5e9a74d214fa61fa2cc0c8e210ff6032b77ab3395ec6210769b8e57e6).

Thanks @sspitsyn @albertnetymk @shipilev @dholmes-ora for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27304#issuecomment-3308332068
PR Comment: https://git.openjdk.org/jdk/pull/27304#issuecomment-3308334286

From iklam at openjdk.org  Thu Sep 18 16:12:21 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 18 Sep 2025 16:12:21 GMT
Subject: Integrated: 8362561: Remove diagnostic option
 AllowArchivingWithJavaAgent
In-Reply-To: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
References: <WbJ_oJq03PbF7nv_WRczx2D3L9AAcXYC8ChxrSkssZw=.17723438-232b-4338-b1c1-25606754dd75@github.com>
Message-ID: <oUoxyzr0lfOBwxYmqsYKaGQOKkaLWAz9LrtVAzg4R6o=.3ae44a7b-8b0a-4925-bed0-a74bb3c120a2@github.com>

On Tue, 16 Sep 2025 03:52:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Goal: simplify AOT implementation and removed unnecessary tests:
> 
> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations).
> 
> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary.
> 
> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production.

This pull request has now been integrated.

Changeset: 000569da
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/000569da601afde85f83c361c9f1a7ba3814bff4
Stats:     1197 lines in 25 files changed: 41 ins; 1146 del; 10 mod

8362561: Remove diagnostic option AllowArchivingWithJavaAgent

Reviewed-by: sspitsyn, shade, dholmes, ayang

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

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

From cjplummer at openjdk.org  Thu Sep 18 18:10:49 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Sep 2025 18:10:49 GMT
Subject: RFR: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing
Message-ID: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>

Fixed an issue with a race with two events coming in close to the same time, the first of which does not suspend any debuggee threads. More details in the first comment.

Tested by running all vmTestbase/nsk/jdi tests 25x times on all platforms both with and w/o virtual threads. Also ran all tier5 svc tests.

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

Commit messages:
 - Fix issue with getting two events quickly

Changes: https://git.openjdk.org/jdk/pull/27370/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27370&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367318
  Stats: 15 lines in 2 files changed: 4 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27370/head:pull/27370

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

From cjplummer at openjdk.org  Thu Sep 18 18:10:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Sep 2025 18:10:50 GMT
Subject: RFR: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing
In-Reply-To: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
References: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
Message-ID: <m-r6-zCdhcrkdBNKBs-e3rQ-lnlrCoKXG-odXYyAdOk=.64c7e345-df43-4266-bd29-762badd37162@github.com>

On Thu, 18 Sep 2025 18:01:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed an issue with a race with two events coming in close to the same time, the first of which does not suspend any debuggee threads. More details in the first comment.
> 
> Tested by running all vmTestbase/nsk/jdi tests 25x times on all platforms both with and w/o virtual threads. Also ran all tier5 svc tests.

The test is dealing with two events. The first event is a MethodExitEvent. The request for it uses SUSPEND_NONE, so the debuggee is not suspended when this event is generated. The second is a BreakpointEvent that is part of the "breakpoint for communication" support. It uses SUSPEND_ALL.

For the MethodExitEvent, the test uses EventHandler.waitForRequestedEvent(), which relies mostly on waitForRequestedEventCommon(). This is where the bug is. It sets up an EventHandler listener, and waits for the listener to be called for the MethodExitEvent.

                while (!isDisconnected() && en.set == null && timeLeft > 0) {
                    EventHandler.this.wait(timeLeft);
                    timeLeft = timeToFinish - System.currentTimeMillis();
                }

The listener will store the EventSet in en.set and the Event in en.event. The event comes in as expected and the listener does a notifyAll() to wakeup the wait(). The problem is before the wait() actually wakes up, the BreakpointEvent comes in. This is because the MethodExitEvent was delivered with SUSPEND_NONE, so the debuggee has continued on to the breakpoint. This means the listener gets called again, even though the MethodExitEvent was already delivered. The listener clears out the en.set field, and then sees that the BreakpointEvent is not the one that was requested, so it returns but leaves en.set set to null. At this point the wait() above returns. It does the "en.set == null" check, and falls back into another wait() call. This one never wakes up with a notifyAll(), but does time out after 5 minutes. There is no error reported when it times out even though en.set is still null. en.event is still properly set, and this is what waitForRequestedEvent() returns, so in the end th
 e test passes, but only after the extra 5 minute delay.

The fix is pretty simple. In the EventHandler listener, if we already got the event we are looking for, then ignore any others that come in. 

Note I also removed the synchronize(EventHandler.this) from the listener. EventHandler.run() already does the same synchronize before calling the listener. I did the same in the listener being used for the "breakoint for communication". I checked all other eventReceived() callbacks, and didn't find any others using this synchronization.

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

PR Comment: https://git.openjdk.org/jdk/pull/27370#issuecomment-3308873649

From fandreuzzi at openjdk.org  Thu Sep 18 21:10:27 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 18 Sep 2025 21:10:27 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <_ibjzLZnC5NGYTnyawKsgT2ZMwEF1WyDqYH_tycmYL4=.dca3377a-eaf2-4b8f-b140-818e19a994cd@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
 <_ibjzLZnC5NGYTnyawKsgT2ZMwEF1WyDqYH_tycmYL4=.dca3377a-eaf2-4b8f-b140-818e19a994cd@github.com>
Message-ID: <UrFoPOqD9E4GHPKbkwA9yZ6JIkXsrTUaWqgf4jKRP5U=.2b4ea5d6-2c8d-4999-b817-bb6a73150617@github.com>

On Thu, 18 Sep 2025 10:26:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - nn
>>  - comment and rename
>
> Thanks - does that still have the same problem?
> (Do you have the jtreg log from this one, to confirm I was looking at the right address here...)
> 
> 
> libjvm second seg:
> core:
> 
> Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   LOAD           0x0000000006b23000 0x00007fa9ff881000 0x0000000000000000
>                  0x0000000000e23000 0x0000000000e23000  R E    0x1000
> 
> 
> libjvm binary:
> 
> LOAD           0x0000000000680180 0x0000000000681180 0x0000000000681180
>                0x0000000000e226c0 0x0000000000e226c0  R E    0x1000
> 
> 			 
> These figures look like they work, for that check which has been working for gcc builds:
> 
> ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size)
> 
> left: 	core file memsize: 0x0000000000e23000
> right: 	lib mem size 0x0000000000e226c0 rounds to 0xe23000
> 	
> Was core 1 different? Looks like a slightly smaller libjvm in that run (mem size was 0e225c0 and the core contained a 0xe24000 size mapping, which was the problem).

Hi @kevinjwalls, I think that might be my fault. I rerun the test and I noticed the failure this time is not in `libjvm.so`, but in `libjimage.so`:

hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5)

% info proc mappings
[...]
0x00007fa9ff0e4000 0x00007fa9ff0fd000 0x19000            0x8000             /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so 

 I think this happens by chance. I added the files from the new round to the ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3309729209

From sspitsyn at openjdk.org  Thu Sep 18 21:32:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 18 Sep 2025 21:32:51 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v11]
In-Reply-To: <qj_yqYpR1zm9eqNvkX4JB4Hz-CDZtWlD3EBPJUEN8MY=.b16fbed1-2c11-4725-b614-8bf3b66b98c8@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <qj_yqYpR1zm9eqNvkX4JB4Hz-CDZtWlD3EBPJUEN8MY=.b16fbed1-2c11-4725-b614-8bf3b66b98c8@github.com>
Message-ID: <o-7HPM0z5TnZTI9eD_ABxtjk0AvFzBVZIT5523bv7eE=.8aa8adad-2a2f-4d3f-b5c2-277073e0934e@github.com>

On Thu, 18 Sep 2025 05:12:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   asseriton moved out

This looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3242159686

From sspitsyn at openjdk.org  Thu Sep 18 21:32:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 18 Sep 2025 21:32:53 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v10]
In-Reply-To: <CrWtZUxBlwr5WopUUWrwdXDSF1DNrjO1WE2gN308L3Q=.90153219-5098-4ad5-8796-8e1d20dfe090@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <UOMOrj6uUEzoTp-BYfEGzv8QUhigbyuef2J1bOtQfpU=.cf52cb97-78cd-4152-add9-3d37375c873c@github.com>
 <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com>
 <z6NY7WoFPPTb9H8wUhit7yhZjdk7uRUPqYauY1deD9I=.9543cc97-3c61-4cc9-ac53-4cd2db7f972c@github.com>
 <eAxIjtOV2yzv-euRGt3acoGNHp2jwyXjduyBXZ9WUf4=.29a6c60a-15fc-428b-ac38-ae8e40e2cffd@github.com>
 <CrWtZUxBlwr5WopUUWrwdXDSF1DNrjO1WE2gN308L3Q=.90153219-5098-4ad5-8796-8e1d20dfe090@github.com>
Message-ID: <qpdYbtvQ9i35PVnj3kS4z9HNHQ8NzL5GxK6J-xo-JtE=.5ca40a8c-6bbc-4632-bcaa-520c2cedbb76@github.com>

On Thu, 18 Sep 2025 04:50:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Thanks - though I find this code rather convoluted. We now always extract the `id` even though we only need it in the `register_vthread_SR == true` case. I tried different re-arrangements of the code to see if it could be cleaner, but the JVMTI part is just messy.
>
> Yes, the id is always extracted and the exposure of "raw" id on this level is not the good desing. However, I don't know how to implement this better.

I'm not sure the exposure of "raw" id on this level is not a good design.
The parameter `register_vthread_SR` looks somewhat messy as it is used under JVMTI ifdef's only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2361236101

From cjplummer at openjdk.org  Thu Sep 18 22:36:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Sep 2025 22:36:13 GMT
Subject: RFR: 8361955: [GCC static analyzer] libjdwp/threadControl.c
 threadControl_setPendingInterrupt error: dereference of NULL 'node'
Message-ID: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>

Fix gcc static analyzer warning. It was introduced by [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) early last year. For the most part the fix is to revert the relevant [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) changes, except for leaving in the replacement of calling findThread() with instead calling findRunningThread().

Ran all svc tier2 and tier5 tests.

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

Commit messages:
 - fix gcc static analyzer warning

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

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

From sspitsyn at openjdk.org  Fri Sep 19 00:27:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 19 Sep 2025 00:27:29 GMT
Subject: RFR: 8367927: Remove 8043571-related tests from problemlists
In-Reply-To: <pVFKMCWCAY4fMq8rzhu_Uq2wAqPrqKLVnpCFwlJNF8w=.d4d0d8d0-b9cd-4fbf-a424-604cd511844d@github.com>
References: <pVFKMCWCAY4fMq8rzhu_Uq2wAqPrqKLVnpCFwlJNF8w=.d4d0d8d0-b9cd-4fbf-a424-604cd511844d@github.com>
Message-ID: <7ehICAjEci5rcQbbWK93Qa5vD9PHFizDqZuTbJsDeRA=.d324ebc1-92c0-4300-8d7b-a967337ed49f@github.com>

On Wed, 17 Sep 2025 18:06:21 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are were few fixes in post_method_exit recently. I tried to reproduce this issue and failed.
> Let remove tests from problemlist and see if it issue is still reproduced in CI.
> 
> The bug https://bugs.openjdk.org/browse/JDK-8043571 remains open so far. It will be closed in jdk26 if not reproduced.

Okay

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27351#pullrequestreview-3242399021

From dholmes at openjdk.org  Fri Sep 19 02:48:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 02:48:27 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
Message-ID: <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com>

On Thu, 18 Sep 2025 07:41:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix rename

This looks good. I think it will be easier to understand for newcomers to the code.

One query: have you done any performance measurements for this change? I'm a little concerned that the insertion iterator and the internal array management is now more heavyweight than the old array management.

I don't understand the existing "operand" terminology and it seems even less appropriate now. It would be good to change this, but can be left for future RFE.

A number of nits, mainly indentation.

Thanks

src/hotspot/share/oops/constantPool.cpp line 1784:

> 1782:     int k1 = from_cp->bootstrap_methods_attribute_index(from_i);
> 1783:     int k2 = from_cp->bootstrap_name_and_type_ref_index_at(from_i);
> 1784:     k1 += to_cp->bsm_entries().array_length();  // to_cp might already have operands

Here and below can we replace "operands" with something better? I didn't understand its use initially and now we don't have an operand array it seems even less informative.

src/hotspot/share/oops/constantPool.cpp line 2303:

> 2301:   st->print("constant pool [%d]", length());
> 2302:   if (has_preresolution()) st->print("/preresolution");
> 2303:   if (!bsm_entries().is_empty())  st->print("/operands[%d]", bsm_entries().bootstrap_methods()->length());

Again is "operands" a meaningful description?

src/hotspot/share/oops/constantPool.cpp line 2358:

> 2356:   InsertionIterator iter = start_extension(other.number_of_entries(), other.array_length(), loader_data, CHECK_(BSMAttributeEntries::InsertionIterator()));
> 2357:   return iter;
> 2358: }

Suggestion:

BSMAttributeEntries::InsertionIterator
BSMAttributeEntries::start_extension(const BSMAttributeEntries& other, ClassLoaderData* loader_data, TRAPS) {
  InsertionIterator iter = start_extension(other.number_of_entries(), other.array_length(), 
                                            loader_data, CHECK_(BSMAttributeEntries::InsertionIterator()));
  return iter;
}

src/hotspot/share/oops/constantPool.cpp line 2362:

> 2360: BSMAttributeEntries::InsertionIterator
> 2361: BSMAttributeEntries::start_extension(int number_of_entries, int array_length,
> 2362:                                    ClassLoaderData* loader_data, TRAPS) {

Suggestion:

                                     ClassLoaderData* loader_data, TRAPS) {

Fix indent

src/hotspot/share/oops/constantPool.cpp line 2391:

> 2389:   other.copy_into(iter, other.number_of_entries());
> 2390:   end_extension(iter, loader_data, THREAD);
> 2391: 

Suggestion:

src/hotspot/share/oops/constantPool.cpp line 2399:

> 2397:   assert(iter._cur_array <= this->_bootstrap_methods->length(), "must be");
> 2398: 
> 2399:   // Did we fill up all of the available space? If so, do nothing

Suggestion:

  // Did we fill up all of the available space? If so, do nothing.

src/hotspot/share/oops/constantPool.hpp line 665:

> 663:   bool compare_bootstrap_entry_to(int bsms_attribute_index1, const constantPoolHandle& cp2,
> 664:                                   int bsms_attribute_index2);
> 665:   // Find a BSM entry in search_cp that matches the BSM at bsm_attribute_index

Suggestion:

  // Find a BSM entry in search_cp that matches the BSM at bsm_attribute_index.

src/hotspot/share/oops/constantPool.hpp line 668:

> 666:   // Return -1 if not found.
> 667:   int find_matching_bsm_entry(int bsms_attribute_index, const constantPoolHandle& search_cp,
> 668:                             int offset_limit);

Suggestion:

  int find_matching_bsm_entry(int bsms_attribute_index, const constantPoolHandle& search_cp,
                              int offset_limit);

Fix indent

src/hotspot/share/oops/constantPool.inline.hpp line 93:

> 91: inline BSMAttributeEntry* BSMAttributeEntries::InsertionIterator::reserve_new_entry(u2 bsmi, u2 argc) {
> 92:   if (_cur_offset + 1 > insert_into->offsets()->length() ||
> 93:       _cur_array + 1 + 1 + argc > insert_into->bootstrap_methods()->length()) {

The `+ 1 + 1 + argc` looks a little magical - can we factor it out and explain it e.g.

int next_array = _cur_array + 1 /* ??? */ + 1 /* ??? */ + argc;
...
_curr_array = next_array;
...

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 713:

> 711:     // forward reference in *merge_cp_p or not a direct match
> 712:     int found_i = scratch_cp->find_matching_bsm_entry(old_bs_i, *merge_cp_p,
> 713:                                                     max_offset_in_merge);

Suggestion:

    int found_i = scratch_cp->find_matching_bsm_entry(old_bs_i, *merge_cp_p,
                                                      max_offset_in_merge);

Fix indent

src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 451:

> 449:   bool merge_constant_pools(const constantPoolHandle& old_cp,
> 450:     const constantPoolHandle& scratch_cp, constantPoolHandle& merge_cp_p,
> 451:     int& merge_cp_length_p, TRAPS);

Pre-existing but none of the line-wrapping indentation is correct in this section of the file.

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

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3237461571
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361464715
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361479948
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361487875
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361489262
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361209369
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361210519
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361528513
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361225007
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361234056
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361542260
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361569102

From dholmes at openjdk.org  Fri Sep 19 02:48:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 02:48:30 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v4]
In-Reply-To: <_l9gNHqLkkeioUXxWsXpWKp01ft-E06ucp_s5JUPwMo=.1879d0bf-aefd-4912-9ec5-f6d4989396f5@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <_l9gNHqLkkeioUXxWsXpWKp01ft-E06ucp_s5JUPwMo=.1879d0bf-aefd-4912-9ec5-f6d4989396f5@github.com>
Message-ID: <ht3Dta_AjjyEgF2pZM5ZvqEMhm3MSOcwfe7ITiuXKT4=.27cbfd4e-cb93-4813-aa25-105ff709d890@github.com>

On Wed, 17 Sep 2025 07:26:34 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/prims/jvmtiRedefineClasses.hpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/oops/constantPool.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

src/hotspot/share/classfile/classFileParser.cpp line 51:

> 49: #include "oops/annotations.hpp"
> 50: #include "oops/constantPool.hpp"
> 51: #include "oops/constantPool.inline.hpp"

Suggestion:

#include "oops/constantPool.inline.hpp"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2357647450

From dholmes at openjdk.org  Fri Sep 19 02:48:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 02:48:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com>
Message-ID: <kHR-vnMseeksUquLbpWcW_KKPo_4HHNO1OIYWi0czjM=.031c66d2-8b7d-476e-8349-7ba9bd76bdda@github.com>

On Tue, 16 Sep 2025 05:52:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix rename
>
> src/hotspot/share/oops/constantPool.cpp line 1625:
> 
>> 1623: void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp,
>> 1624:                                  const constantPoolHandle& to_cp,
>> 1625:                                  TRAPS) {
> 
> Suggestion:
> 
> void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp,
>                                     const constantPoolHandle& to_cp,
>                                     TRAPS) {
> 
> Fix indent

Still not fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361462226

From iklam at openjdk.org  Fri Sep 19 03:06:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 19 Sep 2025 03:06:42 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v2]
In-Reply-To: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
Message-ID: <bkwsxILkq1tzy87KoDhJVR04gGsowxJEfsoZBhywKHg=.da83d39c-83b7-4dc9-adbd-d485503dfb19@github.com>

> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.
> 
> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.

Ioi Lam 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:

 - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
 - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
 - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27303/files
  - new: https://git.openjdk.org/jdk/pull/27303/files/e9d9546a..2504e1a6

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

  Stats: 10736 lines in 233 files changed: 4911 ins; 2614 del; 3211 mod
  Patch: https://git.openjdk.org/jdk/pull/27303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27303/head:pull/27303

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

From iklam at openjdk.org  Fri Sep 19 03:10:35 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 19 Sep 2025 03:10:35 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v2]
In-Reply-To: <vEokeRp1ZhM6gzfRwV1rzDNP03UNTsitVBMSWCOaOdc=.cf771262-0c93-4fc4-939a-fe061bc676d5@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
 <vEokeRp1ZhM6gzfRwV1rzDNP03UNTsitVBMSWCOaOdc=.cf771262-0c93-4fc4-939a-fe061bc676d5@github.com>
Message-ID: <lwI7RQrfQUSzngbOBUzaadqcSc3eRN2KROAA7_GyrCA=.d3231d97-239d-4516-8b66-8f22b7b23709@github.com>

On Tue, 16 Sep 2025 15:57:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam 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:
>> 
>>  - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
>>  - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
>>  - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()
>
> src/hotspot/share/prims/jvm.cpp line 2291:
> 
>> 2289: 
>> 2290: JVM_ENTRY(const char*, JVM_GetClassNameUTF(JNIEnv *env, jclass cls))
>> 2291:   Klass* k = get_klass_considering_redefinition(cls, thread);
> 
> Even if it's a redefined class, it'll have the same name so this isn't necessary.

I usually don't want to make semantic changes in a clean-up PR, but this one seems pretty safe so I changed it anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2361635458

From iklam at openjdk.org  Fri Sep 19 03:10:32 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 19 Sep 2025 03:10:32 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v2]
In-Reply-To: <dqOj9UEjjL0fodNbTx6JqoYi-WvnlYnU6dYoaXJle9M=.b06de883-d892-4f88-97e4-88a6883e7194@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
 <dqOj9UEjjL0fodNbTx6JqoYi-WvnlYnU6dYoaXJle9M=.b06de883-d892-4f88-97e4-88a6883e7194@github.com>
Message-ID: <Cv-xjS__9EJyXkD7IXznecT9uO-2d_XAH1D4mA08KRY=.6b1ca6e3-9c4a-4234-9150-0fcec4c7f318@github.com>

On Tue, 16 Sep 2025 06:41:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam 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:
>> 
>>  - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
>>  - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
>>  - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()
>
> Looks good. Just some minor nits.
> 
> Thanks

Thanks for the comments @dholmes-ora and @coleenp. I've made the changes you suggested.

> I sort of think there's no need for the Klass* version of get_class_considering_redefinition since its callers seem to really want an InstanceKlass. Since it's jvm.cpp, you can probably verify that it's never Klass in these callers.

I think it's valid for some of the functions to be called with a non-instance klass, so I use the `get_instance_klass_considering_redefinition()` version only when the original code was doing an `InstanceKlass::cast()`. 

For functions like this one, I am keeping the type checks in the original code:


JVM_ENTRY(jint, JVM_GetClassMethodsCount(JNIEnv *env, jclass cls))
  Klass* k = get_klass_considering_redefinition(cls, thread);
  return (!k->is_instance_klass()) ? 0 : InstanceKlass::cast(k)->methods()->length();
JVM_END


I did remove the `Klass*` version from jvmThreadState.hpp.

I also updated the comments to reflect the new naming.

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

PR Comment: https://git.openjdk.org/jdk/pull/27303#issuecomment-3310354049

From dholmes at openjdk.org  Fri Sep 19 04:15:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 04:15:58 GMT
Subject: RFR: 8367983: javax/management/monitor/ThreadPoolTest.java and
 StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!
In-Reply-To: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
References: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
Message-ID: <4htUvWnHZoK4GC500TSKYWWpm_1hS2RBf65RTNg03v4=.8aaf9de1-e680-4603-8b2d-0fdd00917403@github.com>

On Thu, 18 Sep 2025 11:47:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has failed due to a timing issue, but not continually or reproducibly.
> Looks like an effect of the TIMEOUT_FACTOR change (8260555).
> 
> The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0
> 
> We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.ack a few years, so multiply the current 500ms by a little more than 4.

LGTM2

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27361#pullrequestreview-3242817275

From dholmes at openjdk.org  Fri Sep 19 04:49:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 04:49:23 GMT
Subject: RFR: 8361955: [GCC static analyzer] libjdwp/threadControl.c
 threadControl_setPendingInterrupt error: dereference of NULL 'node'
In-Reply-To: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
References: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
Message-ID: <JgnEt8teC5AFQDbZbBTohT9Tjq8hlzvZQQLF4hrJvuE=.69f4233e-3c65-4cf3-bc1d-5a08465242c2@github.com>

On Thu, 18 Sep 2025 22:26:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix gcc static analyzer warning. It was introduced by [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) early last year. For the most part the fix is to revert the relevant [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) changes, except for leaving in the replacement of calling findThread() with instead calling findRunningThread().
> 
> Ran all svc tier2 and tier5 tests.

It fixes the warning but surely impossible to be calling this function in such circumstances?

Static analyzers often lack context that would tell them something can't be null. Normally, in main hotspot code, asserts seem to do the job of telling the analyzer this.

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

PR Review: https://git.openjdk.org/jdk/pull/27378#pullrequestreview-3242922515

From dholmes at openjdk.org  Fri Sep 19 06:00:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 06:00:43 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v2]
In-Reply-To: <bkwsxILkq1tzy87KoDhJVR04gGsowxJEfsoZBhywKHg=.da83d39c-83b7-4dc9-adbd-d485503dfb19@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
 <bkwsxILkq1tzy87KoDhJVR04gGsowxJEfsoZBhywKHg=.da83d39c-83b7-4dc9-adbd-d485503dfb19@github.com>
Message-ID: <H0F6oC-a5Hm_C4QsX_kJQ2x0zHe-gVqY4nGfas6ujzw=.80b9a9cd-dce2-43d4-ab3c-fb9be87a78da@github.com>

On Fri, 19 Sep 2025 03:06:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.
>> 
>> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.
>
> Ioi Lam 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:
> 
>  - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
>  - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
>  - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()

Looks good! Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3243228173

From dholmes at openjdk.org  Fri Sep 19 06:02:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 06:02:19 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v11]
In-Reply-To: <qj_yqYpR1zm9eqNvkX4JB4Hz-CDZtWlD3EBPJUEN8MY=.b16fbed1-2c11-4725-b614-8bf3b66b98c8@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <qj_yqYpR1zm9eqNvkX4JB4Hz-CDZtWlD3EBPJUEN8MY=.b16fbed1-2c11-4725-b614-8bf3b66b98c8@github.com>
Message-ID: <fGzqhKcmomiGf6SJ3DZSkXG9cTVyP_bXAtruvDkkg2w=.5bb3e598-5b8b-4375-bd23-452c57b66e03@github.com>

On Thu, 18 Sep 2025 05:12:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   asseriton moved out

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3243235465

From cjplummer at openjdk.org  Fri Sep 19 06:30:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 19 Sep 2025 06:30:17 GMT
Subject: RFR: 8361955: [GCC static analyzer] libjdwp/threadControl.c
 threadControl_setPendingInterrupt error: dereference of NULL 'node'
In-Reply-To: <JgnEt8teC5AFQDbZbBTohT9Tjq8hlzvZQQLF4hrJvuE=.69f4233e-3c65-4cf3-bc1d-5a08465242c2@github.com>
References: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
 <JgnEt8teC5AFQDbZbBTohT9Tjq8hlzvZQQLF4hrJvuE=.69f4233e-3c65-4cf3-bc1d-5a08465242c2@github.com>
Message-ID: <12Q2KvXEOix-_XMr1qe-uT5IKzcFBTJ10tXT5LI8_wg=.fc7a2c9e-8b37-42d7-a3ea-7baa1e1f1ff0@github.com>

On Fri, 19 Sep 2025 04:47:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fix gcc static analyzer warning. It was introduced by [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) early last year. For the most part the fix is to revert the relevant [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) changes, except for leaving in the replacement of calling findThread() with instead calling findRunningThread().
>> 
>> Ran all svc tier2 and tier5 tests.
>
> It fixes the warning but surely impossible to be calling this function in such circumstances?
> 
> Static analyzers often lack context that would tell them something can't be null. Normally, in main hotspot code, asserts seem to do the job of telling the analyzer this.

@dholmes-ora Can you read through the CR? There are more details there on why in the end I decided to go ahead and make this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/27378#issuecomment-3310786920

From sjohanss at openjdk.org  Fri Sep 19 07:10:36 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 19 Sep 2025 07:10:36 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v4]
In-Reply-To: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
Message-ID: <OcgKVUeBKMbMK8P87BbGbCyVT4YxCsj_yfibBzqb3Ao=.830efb36-8175-4474-bcd0-a70ff2cf0511@github.com>

> Please review this enhancement to the smaps parser and printer.
> 
> **Summary**
> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
> 
> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
> 
> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
> 
> **Testing**
> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

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

  Thomas review
  
  Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27098/files
  - new: https://git.openjdk.org/jdk/pull/27098/files/d9aa3c29..7b3d9f93

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

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

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

From sjohanss at openjdk.org  Fri Sep 19 07:10:38 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 19 Sep 2025 07:10:38 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v3]
In-Reply-To: <Jj7iJXaT6bJfBqfMRstEFwbT6rcVYVmosVnHNPIW5Dw=.9b9c60dc-96e2-49e7-8ca0-df4fe4dfc8c3@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
 <Jj7iJXaT6bJfBqfMRstEFwbT6rcVYVmosVnHNPIW5Dw=.9b9c60dc-96e2-49e7-8ca0-df4fe4dfc8c3@github.com>
Message-ID: <5FvVmBPrBoK5ADJlt3xk9V4688o6m1Ga7jQd20Jqsko=.795c4183-98ca-4108-9bc4-f887cb0740c2@github.com>

On Fri, 5 Sep 2025 09:24:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Offline comments and discussion
>
> Marked as reviewed by ayang (Reviewer).

Thanks for the reviews @albertnetymk and @tstuefe. Will need a re-review since I applied the suggestions above.

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

PR Comment: https://git.openjdk.org/jdk/pull/27098#issuecomment-3310926625

From prr at openjdk.org  Fri Sep 19 07:24:51 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 19 Sep 2025 07:24:51 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
 <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>
Message-ID: <NL0v01IMgDJJju_MFEPumkhfuFnX3ilRWbDzKOkWVlA=.97429c51-f72c-4218-a382-b720831a81b1@github.com>

On Thu, 18 Sep 2025 13:37:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I have started a verification job with tier1-5.

If that passes, then it is very likely OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3310536470

From mbaesken at openjdk.org  Fri Sep 19 07:24:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Sep 2025 07:24:55 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
Message-ID: <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>

On Thu, 18 Sep 2025 14:36:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used.


Is there some test for this special functionality?

The comments in the C sources
https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libsyslookup/syslookup.c

do not really help me to understand what functions from libdl we want to bring in this way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2362019646

From mbaesken at openjdk.org  Fri Sep 19 07:24:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Sep 2025 07:24:53 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <gd_5h2ho7Pr5DuHfHkY05xyYpu2cXSi149sZOitcJGc=.79e7a719-75a6-4c41-9182-c6d1e5a560d7@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

I can bring back  the LIBDL  dependency  of   BUILD_LIBSYSLOOKUP if we are unsure about this single removal.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3310964805

From stuefe at openjdk.org  Fri Sep 19 08:08:23 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 19 Sep 2025 08:08:23 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v4]
In-Reply-To: <OcgKVUeBKMbMK8P87BbGbCyVT4YxCsj_yfibBzqb3Ao=.830efb36-8175-4474-bcd0-a70ff2cf0511@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <OcgKVUeBKMbMK8P87BbGbCyVT4YxCsj_yfibBzqb3Ao=.830efb36-8175-4474-bcd0-a70ff2cf0511@github.com>
Message-ID: <Va9cm-ulXrPO9cH1v612zBrsrAzuW3eNPuZ49J9jJDg=.f864e7f3-5323-4fef-a06c-d7de3a8cda75@github.com>

On Fri, 19 Sep 2025 07:10:36 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to the smaps parser and printer.
>> 
>> **Summary**
>> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
>> 
>> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
>> 
>> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
>> 
>> **Testing**
>> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas review
>   
>   Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>

Still good

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27098#pullrequestreview-3243690046

From kevinw at openjdk.org  Fri Sep 19 08:19:05 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 19 Sep 2025 08:19:05 GMT
Subject: RFR: 8367983: javax/management/monitor/ThreadPoolTest.java and
 StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!
In-Reply-To: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
References: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
Message-ID: <3XNu1_EV5fIf2MV5We8GbXoegYD5SFtBCBrw8arOUBE=.18c71478-e70a-4202-8a99-b11f68736032@github.com>

On Thu, 18 Sep 2025 11:47:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has failed due to a timing issue, but not continually or reproducibly.
> Looks like an effect of the TIMEOUT_FACTOR change (8260555).
> 
> The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0
> 
> We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27361#issuecomment-3311117973

From kevinw at openjdk.org  Fri Sep 19 08:19:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 19 Sep 2025 08:19:06 GMT
Subject: Integrated: 8367983: javax/management/monitor/ThreadPoolTest.java and
 StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!
In-Reply-To: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
References: <flg7qNs55dKhwkveIDKuZ45MCIijgL6evKZNns1_fDY=.d3ebc0bc-b8d1-4444-b92b-9d063627675e@github.com>
Message-ID: <m7Nu1nQiwRKvRPbQAvV12uxXzZoObdTKdQETJ5bpAF0=.046c6ca6-1c96-4908-9c1f-65e3a6710493@github.com>

On Thu, 18 Sep 2025 11:47:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has failed due to a timing issue, but not continually or reproducibly.
> Looks like an effect of the TIMEOUT_FACTOR change (8260555).
> 
> The recent failure has -J-Dtest.timeout.factor=1.0 and I see older logs passing with -Dtest.timeout.factor=4.0
> 
> We should increase the timeout.  As there have been occasional failures before, looking back a few years, so multiply the current 500ms by a little more than 4.

This pull request has now been integrated.

Changeset: 930d7249
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/930d7249239e464adfca3a007342ce0fcb8f070d
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8367983: javax/management/monitor/ThreadPoolTest.java and StartStopTest.java fail with Unexpected Maximum Pool Size Overflow!

Reviewed-by: cjplummer, dholmes

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

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

From sjohanss at openjdk.org  Fri Sep 19 08:52:01 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 19 Sep 2025 08:52:01 GMT
Subject: Integrated: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field
In-Reply-To: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
Message-ID: <Bb-dYMzxjH5duGPaIf6IrWnqWKCy26ybUIvC85g1Vko=.2dfa81f8-b24c-4ce2-be4c-3598685c8ad5@github.com>

On Thu, 4 Sep 2025 14:19:06 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement to the smaps parser and printer.
> 
> **Summary**
> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
> 
> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
> 
> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
> 
> **Testing**
> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

This pull request has now been integrated.

Changeset: 937e19e8
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/937e19e86aab9194c363fb8709bbbc6dead0c391
Stats:     16 lines in 4 files changed: 12 ins; 1 del; 3 mod

8366780: Enhance ProcSmapsParser and Printer to handle THPeligible field

Reviewed-by: stuefe, ayang

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

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

From ihse at openjdk.org  Fri Sep 19 09:11:25 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 09:11:25 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <BkK2R8rxY9PzEt72KHMr8DN95MVqkaAVJcGctyaMvVM=.6549f83d-e513-4485-bd76-c40b1fcbc9e5@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

I've pinged Maurizio about libsyslookup; let's hear what he says first.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3311373364

From ihse at openjdk.org  Fri Sep 19 09:11:28 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 09:11:28 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
 <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
Message-ID: <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>

On Fri, 19 Sep 2025 07:20:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 165:
>> 
>>> 163:     LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
>>> 164:     LDFLAGS_aix := -brtl -bexpfull, \
>>> 165:     LIBS_linux := $(LIBDL) $(LIBM), \
>> 
>> I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used.
>
>> I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used.
> 
> 
> Is there some test for this special functionality?
> 
> The comments in the C sources
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libsyslookup/syslookup.c
> 
> do not really help me to understand what functions from libdl we want to bring in this way.

@mcimadamore Can you help us here? libsyslookup has a dependency to libdl, but it is not used. Can we remove that from the linker command line, or would it somehow break libsyslookup? (I have just a very  fuzzy idea of the point of this library.) If we try to remove it, what tests do we need to run to make sure we do not break anything?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2362260334

From kevinw at openjdk.org  Fri Sep 19 10:27:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 19 Sep 2025 10:27:53 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <UrFoPOqD9E4GHPKbkwA9yZ6JIkXsrTUaWqgf4jKRP5U=.2b4ea5d6-2c8d-4999-b817-bb6a73150617@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
 <_ibjzLZnC5NGYTnyawKsgT2ZMwEF1WyDqYH_tycmYL4=.dca3377a-eaf2-4b8f-b140-818e19a994cd@github.com>
 <UrFoPOqD9E4GHPKbkwA9yZ6JIkXsrTUaWqgf4jKRP5U=.2b4ea5d6-2c8d-4999-b817-bb6a73150617@github.com>
Message-ID: <ZDmBj_F3D7R0YMAc44cXy_PvzRVyYRlIJZSgkfxjGGs=.651e82c4-9a72-47d6-a5fb-41e17d2241b0@github.com>

On Thu, 18 Sep 2025 21:07:39 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> failure this time is not in `libjvm.so`, but in `libjimage.so`:

Thanks looking again - do you still have the files, as libjimage_sections.txt  ... has the Section Headers, not the Program Headers (readelf -a is fine 8-) )

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

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3311626276

From coleenp at openjdk.org  Fri Sep 19 11:47:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Sep 2025 11:47:56 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v2]
In-Reply-To: <bkwsxILkq1tzy87KoDhJVR04gGsowxJEfsoZBhywKHg=.da83d39c-83b7-4dc9-adbd-d485503dfb19@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
 <bkwsxILkq1tzy87KoDhJVR04gGsowxJEfsoZBhywKHg=.da83d39c-83b7-4dc9-adbd-d485503dfb19@github.com>
Message-ID: <WMncT7C5fIEynaN1IiomnpeMkIAqhEc2mNLdmG08_5Y=.136eca5b-0544-4456-ae36-d0240a0d7fb2@github.com>

On Fri, 19 Sep 2025 03:06:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.
>> 
>> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.
>
> Ioi Lam 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:
> 
>  - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
>  - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
>  - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()

Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3244497323

From jsjolen at openjdk.org  Fri Sep 19 11:50:59 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 19 Sep 2025 11:50:59 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com>
Message-ID: <4sDHlKErEtUHt0Y6uxCcqxnQX5Ztl8gNYsd8t_9pnmc=.7a7bf590-9e18-424c-9992-2d65d264c075@github.com>

On Fri, 19 Sep 2025 02:45:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>One query: have you done any performance measurements for this change? I'm a little concerned that the insertion iterator and the internal array management is now more heavyweight than the old array management.

I haven'e done any performance testing. I was considering doing so, but the majority of the work that has potentially been slowed down is when redefining classes via JVMTI, as this is when we got to do what essentially boiled down to a `memcpy`. My understanding of JVMTI is that it's less performance sensitive than the usual JVM, as it's only used or tooling on a 'human' level (debuggers, etc). Is that understanding correct?

Regardless, I'll have a look at doing some coarse-grained profiling via Aurora, and also have a look at the generated assembly. The goal of putting some of the functions in the inline file was to give enough context to the compiler so that it can do a good job of optimizing the code, we'll see if that was actually the case.

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3311891616

From ihse at openjdk.org  Fri Sep 19 12:45:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 12:45:46 GMT
Subject: RFR: 8368094: Fix problem list errors
Message-ID: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>

I am trying to add `--verify-excludes` to all jtreg runs. This new flag will let jtreg catch (at least some) mistakes in problem lists. There are some technical hurdles remaining to add this option, but in the meantime I thought I could at least fix those issues I have found so far. This is not exhaustive, I am sure there are more issues that will be discovered, but these are at least real errors that can be fixed.

For reviewing, I recommend looking at the individual commits where I give a reason for each change.

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

Commit messages:
 - Duplicate lines are not allowed
 - PermissionTest.java was removed in JDK-8338411
 - CustomSecurityManagerTest.java was removed in JDK-8338411
 - GetStackTraceWhenRunnable.java was removed in JDK-8336254
 - DebugdUtils.java is a helper class, not a test
 - The LingeredApp* classes are helpers and not tests
 - ClhsdbScanOops.java contains two tests; give them ids and exclude both
 - Can't exclude ClhsdbPmap.java as a whole, the two included tests are already excluded
 - ClhsdbLauncher.java is a helper class, not a test
 - JMapHProfLargeHeapProc is a helper class, not a test
 - ... and 4 more: https://git.openjdk.org/jdk/compare/87d50425...a04276e9

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

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

From dholmes at openjdk.org  Fri Sep 19 12:47:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 12:47:31 GMT
Subject: RFR: 8361955: [GCC static analyzer] libjdwp/threadControl.c
 threadControl_setPendingInterrupt error: dereference of NULL 'node'
In-Reply-To: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
References: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
Message-ID: <Efz5ajAxsyobvEKHAyzLOBHlohjsj8yALA4xTOr_Js4=.a446adaf-05e4-4460-9fbf-be1f4e5ef720@github.com>

On Thu, 18 Sep 2025 22:26:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix gcc static analyzer warning. It was introduced by [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) early last year. For the most part the fix is to revert the relevant [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) changes, except for leaving in the replacement of calling findThread() with instead calling findRunningThread().
> 
> Ran all svc tier2 and tier5 tests.

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27378#pullrequestreview-3244703155

From dholmes at openjdk.org  Fri Sep 19 12:47:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 12:47:33 GMT
Subject: RFR: 8361955: [GCC static analyzer] libjdwp/threadControl.c
 threadControl_setPendingInterrupt error: dereference of NULL 'node'
In-Reply-To: <JgnEt8teC5AFQDbZbBTohT9Tjq8hlzvZQQLF4hrJvuE=.69f4233e-3c65-4cf3-bc1d-5a08465242c2@github.com>
References: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
 <JgnEt8teC5AFQDbZbBTohT9Tjq8hlzvZQQLF4hrJvuE=.69f4233e-3c65-4cf3-bc1d-5a08465242c2@github.com>
Message-ID: <vC-sBJjjYYBnvgr33Dm5xecPigQP4PD_-ULcmSKbWJI=.216acdf4-fd3d-4e5d-ba2f-5c80b1f1c145@github.com>

On Fri, 19 Sep 2025 04:47:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fix gcc static analyzer warning. It was introduced by [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) early last year. For the most part the fix is to revert the relevant [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) changes, except for leaving in the replacement of calling findThread() with instead calling findRunningThread().
>> 
>> Ran all svc tier2 and tier5 tests.
>
> It fixes the warning but surely impossible to be calling this function in such circumstances?
> 
> Static analyzers often lack context that would tell them something can't be null. Normally, in main hotspot code, asserts seem to do the job of telling the analyzer this.

> @dholmes-ora Can you read through the CR? There are more details there on why in the end I decided to go ahead and make this change.

Okay I see the full story now.

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

PR Comment: https://git.openjdk.org/jdk/pull/27378#issuecomment-3312060939

From erikj at openjdk.org  Fri Sep 19 12:52:38 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 19 Sep 2025 12:52:38 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <NL0v01IMgDJJju_MFEPumkhfuFnX3ilRWbDzKOkWVlA=.97429c51-f72c-4218-a382-b720831a81b1@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
 <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>
 <NL0v01IMgDJJju_MFEPumkhfuFnX3ilRWbDzKOkWVlA=.97429c51-f72c-4218-a382-b720831a81b1@github.com>
Message-ID: <k-ErB2Uzn7cQcQ1lmFQGCVGxuZFGeRhzsjT-g_t_QVA=.05600278-1b61-464d-9f2c-645767a05d62@github.com>

On Fri, 19 Sep 2025 04:43:29 GMT, Phil Race <prr at openjdk.org> wrote:

> I have started a verification job with tier1-5.

Job has completed. There were 2 failures, one had lots of recent history of failing, so seems unrelated. The other was a crash that seemed unusual, but it passed on a rerun. So I think we can say this passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3312072392

From mbaesken at openjdk.org  Fri Sep 19 12:52:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Sep 2025 12:52:39 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <k-ErB2Uzn7cQcQ1lmFQGCVGxuZFGeRhzsjT-g_t_QVA=.05600278-1b61-464d-9f2c-645767a05d62@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
 <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>
 <NL0v01IMgDJJju_MFEPumkhfuFnX3ilRWbDzKOkWVlA=.97429c51-f72c-4218-a382-b720831a81b1@github.com>
 <k-ErB2Uzn7cQcQ1lmFQGCVGxuZFGeRhzsjT-g_t_QVA=.05600278-1b61-464d-9f2c-645767a05d62@github.com>
Message-ID: <bkYc0lk7sATs4w1qSEdV16QC4sXMMlp6Y6zi1ag4WSc=.813768a2-e48a-437e-818c-35c7c30cd2f5@github.com>

On Fri, 19 Sep 2025 12:48:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > I have started a verification job with tier1-5.
> 
> Job has completed. There were 2 failures, one had lots of recent history of failing, so seems unrelated. The other was a crash that seemed unusual, but it passed on a rerun. So I think we can say this passed.


Thanks for the testing !  So let's wait for some feedback on  libsyslookup  .

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3312079386

From dholmes at openjdk.org  Fri Sep 19 12:59:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 12:59:04 GMT
Subject: RFR: 8368094: Fix problem list errors
In-Reply-To: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
References: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
Message-ID: <gerdqh4vgpb9oAhG0lXeevXhBGILZt-iXNWi0BSHKN0=.f4bbdb31-8c46-4ad4-8db7-d6e3a797d2ec@github.com>

On Fri, 19 Sep 2025 12:38:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I am trying to add `--verify-excludes` to all jtreg runs. This new flag will let jtreg catch (at least some) mistakes in problem lists. There are some technical hurdles remaining to add this option, but in the meantime I thought I could at least fix those issues I have found so far. This is not exhaustive, I am sure there are more issues that will be discovered, but these are at least real errors that can be fixed.
> 
> For reviewing, I recommend looking at the individual commits where I give a reason for each change.

This all seems very reasonable.

Thanks for cleaning this up.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27391#pullrequestreview-3244744835

From duke at openjdk.org  Fri Sep 19 14:12:13 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Fri, 19 Sep 2025 14:12:13 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
Message-ID: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>

`jcmd` provides great diagnostics but many commands lack a timestamp in their output.
Adding a timestamp to the output of some would add value for those debugging JVM data.

Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.

Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.

The exceptions are:
* `VM.uptime` - command run with `-date` argument will also print a timestamp;
* `VM.system_properties` - already lists timestamp
* `Thread.dump_to_file` - the content dumped to file already has a timestamp;
* `VM.version`

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

Commit messages:
 - copyright change
 - Thread.dump_to_file doesn't need timestamp in STDOUT
 - CodeCacheTest.java and ClassHierarchyTest.java to account for added timestamp
 - jcmd [PID] Compiler.perfmap has no valuable stdout. Remove timestamp from Compiler.perfmap
 - 8357828: add timestamps to jcmd diagnostic commands

Changes: https://git.openjdk.org/jdk/pull/27368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357828
  Stats: 45 lines in 4 files changed: 38 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368

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

From alanb at openjdk.org  Fri Sep 19 14:12:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Sep 2025 14:12:15 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <mrItWSSx-0HdN3H5sOt0E89ep28sjp7qHOE0s6KOyuU=.7a9eced4-6211-4dab-8468-137e8116a634@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

src/hotspot/share/services/diagnosticCommand.cpp line 1093:

> 1091: 
> 1092: void ThreadDumpToFileDCmd::execute(DCmdSource source, TRAPS) {
> 1093:   print_local_time(output());

I assume you didn't mean to print a time stamp here as the output already has a timestamp. Also for -format=json and sending the output to stdout, then it will be unparsable if a timestamp appears before the JSON object.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27368#discussion_r2361986465

From duke at openjdk.org  Fri Sep 19 14:12:15 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Fri, 19 Sep 2025 14:12:15 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <mrItWSSx-0HdN3H5sOt0E89ep28sjp7qHOE0s6KOyuU=.7a9eced4-6211-4dab-8468-137e8116a634@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <mrItWSSx-0HdN3H5sOt0E89ep28sjp7qHOE0s6KOyuU=.7a9eced4-6211-4dab-8468-137e8116a634@github.com>
Message-ID: <vYmNnzzS3b8HTA0Tv0CpOVH2itoGd244TPbd5BIbzY0=.304f800e-a464-42b6-91d1-9307b0742868@github.com>

On Fri, 19 Sep 2025 07:02:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
>> Adding a timestamp to the output of some would add value for those debugging JVM data.
>> 
>> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.
>> 
>> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
>> 
>> The exceptions are:
>> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
>> * `VM.system_properties` - already lists timestamp
>> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
>> * `VM.version`
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1093:
> 
>> 1091: 
>> 1092: void ThreadDumpToFileDCmd::execute(DCmdSource source, TRAPS) {
>> 1093:   print_local_time(output());
> 
> I assume you didn't mean to print a time stamp here as the output already has a timestamp. Also for -format=json and sending the output to stdout, then it will be unparsable if a timestamp appears before the JSON object.

Hi Alan. That's right.
My mistake. I declared the intention to not have timestamps for commands with a throwaway `stdout`. This also includes "Thread.dump_to_file" command but then mistakenly added `print_local_time()` in here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27368#discussion_r2362306527

From duke at openjdk.org  Fri Sep 19 14:16:01 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Fri, 19 Sep 2025 14:16:01 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <oMzEa3-aVReKjwNsRaDHJ2x7XGPiaKOHEzR4Bu-cN2Q=.b6aba967-8699-44e7-a9d3-d083777f2571@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

Internal testing tier 1-5 did not show any issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3312364497

From lmesnik at openjdk.org  Fri Sep 19 15:23:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 19 Sep 2025 15:23:34 GMT
Subject: RFR: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked [v11]
In-Reply-To: <qj_yqYpR1zm9eqNvkX4JB4Hz-CDZtWlD3EBPJUEN8MY=.b16fbed1-2c11-4725-b614-8bf3b66b98c8@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
 <qj_yqYpR1zm9eqNvkX4JB4Hz-CDZtWlD3EBPJUEN8MY=.b16fbed1-2c11-4725-b614-8bf3b66b98c8@github.com>
Message-ID: <VLAGrTitEvI5JPK6bDDf-s4riXvHjxZbDmYOB6gA-yc=.c05ea217-eaea-47b3-84be-00179ec1fa6c@github.com>

On Thu, 18 Sep 2025 05:12:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The
>> `SuspendResumeManager::suspend(bool register_vthread_SR)`
>> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
>> 
>> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
>> 
>> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   asseriton moved out

@dholmes-ora, @pchilano, @sspitsyn Thank you for review and feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/27317#issuecomment-3312615550

From lmesnik at openjdk.org  Fri Sep 19 15:23:36 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 19 Sep 2025 15:23:36 GMT
Subject: Integrated: 8367725: Incorrect reading of oop in
 SuspendResumeManager::suspend while thread is blocked
In-Reply-To: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
References: <nU7i6qwx4KyZvf9G3zQNaFC80SCG7zO60UU33GdwhGo=.ee317546-572e-48a5-b088-1c5f6068d746@github.com>
Message-ID: <3fxcQhiRsRMlpH0m5dtfkz7n8HhpRupZjwMoXGijj1g=.c25a8bbc-fa87-4581-abe9-e3203d9460b6@github.com>

On Tue, 16 Sep 2025 15:55:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The
> `SuspendResumeManager::suspend(bool register_vthread_SR)`
> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. 
> 
> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. 
> 
> The fix added some "asymmetry"  in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart.

This pull request has now been integrated.

Changeset: 16458b60
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16458b60c9ccdfac60140c8186f31d5d8a57f2f9
Stats:     43 lines in 5 files changed: 35 ins; 1 del; 7 mod

8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked

Reviewed-by: pchilanomate, dholmes, sspitsyn

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

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

From lmesnik at openjdk.org  Fri Sep 19 15:52:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 19 Sep 2025 15:52:46 GMT
Subject: RFR: 8367927: Remove 8043571-related tests from problemlists
In-Reply-To: <pVFKMCWCAY4fMq8rzhu_Uq2wAqPrqKLVnpCFwlJNF8w=.d4d0d8d0-b9cd-4fbf-a424-604cd511844d@github.com>
References: <pVFKMCWCAY4fMq8rzhu_Uq2wAqPrqKLVnpCFwlJNF8w=.d4d0d8d0-b9cd-4fbf-a424-604cd511844d@github.com>
Message-ID: <jXfwE_0upw1_EJILNzdvp2xpCNOYsnowvYqlDpxQ4X8=.e9c2378f-fb56-4733-8457-0ff88407a3c7@github.com>

On Wed, 17 Sep 2025 18:06:21 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are were few fixes in post_method_exit recently. I tried to reproduce this issue and failed.
> Let remove tests from problemlist and see if it issue is still reproduced in CI.
> 
> The bug https://bugs.openjdk.org/browse/JDK-8043571 remains open so far. It will be closed in jdk26 if not reproduced.

@dholmes-ora, @sspitsyn Thank you for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27351#issuecomment-3312710603

From lmesnik at openjdk.org  Fri Sep 19 15:52:48 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 19 Sep 2025 15:52:48 GMT
Subject: Integrated: 8367927: Remove 8043571-related tests from problemlists
In-Reply-To: <pVFKMCWCAY4fMq8rzhu_Uq2wAqPrqKLVnpCFwlJNF8w=.d4d0d8d0-b9cd-4fbf-a424-604cd511844d@github.com>
References: <pVFKMCWCAY4fMq8rzhu_Uq2wAqPrqKLVnpCFwlJNF8w=.d4d0d8d0-b9cd-4fbf-a424-604cd511844d@github.com>
Message-ID: <YyDOvKBjwC4nsJK8gxCP1rkKNpha_f8cFR9E1724kjk=.223a9aad-df91-41e5-94a9-9248af7fd5b7@github.com>

On Wed, 17 Sep 2025 18:06:21 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are were few fixes in post_method_exit recently. I tried to reproduce this issue and failed.
> Let remove tests from problemlist and see if it issue is still reproduced in CI.
> 
> The bug https://bugs.openjdk.org/browse/JDK-8043571 remains open so far. It will be closed in jdk26 if not reproduced.

This pull request has now been integrated.

Changeset: 695e36b0
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/695e36b0031be4d013ad149a0f23c36c0669c422
Stats:     7 lines in 3 files changed: 0 ins; 6 del; 1 mod

8367927: Remove 8043571-related tests from problemlists

Reviewed-by: dholmes, sspitsyn

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

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

From coleenp at openjdk.org  Fri Sep 19 16:32:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Sep 2025 16:32:37 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
Message-ID: <j5moEV1aWKIQF5Zhfgqu4uzBrO6V6AzSKLcUaieZvkg=.2c79d4fb-f0af-413c-83f4-bfaeb983cd57@github.com>

On Thu, 18 Sep 2025 07:41:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix rename

I really like this except let's make a new file for this type.

You might want @sspitsyn  to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays.

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

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3245777812
PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3312867807

From aivanov at openjdk.org  Fri Sep 19 18:47:38 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Sep 2025 18:47:38 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <UXOkGVZd9q2spYKsQtxziAqvkaa8akLvLSYZ-SdbbPQ=.708f7081-b007-4c31-a016-86c07c225825@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3246478887

From fandreuzzi at openjdk.org  Fri Sep 19 20:56:13 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 19 Sep 2025 20:56:13 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <ZDmBj_F3D7R0YMAc44cXy_PvzRVyYRlIJZSgkfxjGGs=.651e82c4-9a72-47d6-a5fb-41e17d2241b0@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
 <_ibjzLZnC5NGYTnyawKsgT2ZMwEF1WyDqYH_tycmYL4=.dca3377a-eaf2-4b8f-b140-818e19a994cd@github.com>
 <UrFoPOqD9E4GHPKbkwA9yZ6JIkXsrTUaWqgf4jKRP5U=.2b4ea5d6-2c8d-4999-b817-bb6a73150617@github.com>
 <ZDmBj_F3D7R0YMAc44cXy_PvzRVyYRlIJZSgkfxjGGs=.651e82c4-9a72-47d6-a5fb-41e17d2241b0@github.com>
Message-ID: <uhrcsQ5nSx4AJK9LMHaa0RpikRMeESrD11ptdQXStgk=.19c1fcda-8a6c-4a88-98a8-8c65e2a8a9fa@github.com>

On Fri, 19 Sep 2025 10:25:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hi @kevinjwalls, I think that might be my fault. I rerun the test and I noticed the failure this time is not in `libjvm.so`, but in `libjimage.so`:
>> 
>> hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5)
>> 
>> % info proc mappings
>> [...]
>> 0x00007fa9ff0e4000 0x00007fa9ff0fd000 0x19000            0x8000             /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so 
>> 
>>  I think this happens by chance. I added the files from the new round to the ticket.
>
>> failure this time is not in `libjvm.so`, but in `libjimage.so`:
> 
> Thanks looking again - do you still have the files, as libjimage_sections.txt  ... has the Section Headers, not the Program Headers (readelf -a is fine 8-) )

Hi @kevinjwalls, I just uploaded `3libjimage_all.txt`, thanks again for looking into this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3313775487

From dcubed at openjdk.org  Fri Sep 19 21:37:15 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 19 Sep 2025 21:37:15 GMT
Subject: RFR: 8368094: Fix problem list errors
In-Reply-To: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
References: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
Message-ID: <5486UDwCa_HdaZHPYqV3ivRBDijCOd57btBRZlaPEck=.b48c3998-617c-4c80-822e-ce4e13a3cd60@github.com>

On Fri, 19 Sep 2025 12:38:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I am trying to add `--verify-excludes` to all jtreg runs. This new flag will let jtreg catch (at least some) mistakes in problem lists. There are some technical hurdles remaining to add this option, but in the meantime I thought I could at least fix those issues I have found so far. This is not exhaustive, I am sure there are more issues that will be discovered, but these are at least real errors that can be fixed.
> 
> For reviewing, I recommend looking at the individual commits where I give a reason for each change.

Marked as reviewed by dcubed (Reviewer).

Went thru the commits 1-by-1, all are very reasonable.

Thumbs up.

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

PR Review: https://git.openjdk.org/jdk/pull/27391#pullrequestreview-3247212376
PR Comment: https://git.openjdk.org/jdk/pull/27391#issuecomment-3313898320

From cjplummer at openjdk.org  Fri Sep 19 22:05:21 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 19 Sep 2025 22:05:21 GMT
Subject: RFR: 8368094: Fix problem list errors
In-Reply-To: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
References: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
Message-ID: <F7V6aT07q1LW8SGiFox1X8EsvPZ3IXscUYGCBybg1Fs=.7af8cf43-2672-4f13-bade-66e65b9fea05@github.com>

On Fri, 19 Sep 2025 12:38:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I am trying to add `--verify-excludes` to all jtreg runs. This new flag will let jtreg catch (at least some) mistakes in problem lists. There are some technical hurdles remaining to add this option, but in the meantime I thought I could at least fix those issues I have found so far. This is not exhaustive, I am sure there are more issues that will be discovered, but these are at least real errors that can be fixed.
> 
> For reviewing, I recommend looking at the individual commits where I give a reason for each change.

The SA changes all look good.

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

PR Review: https://git.openjdk.org/jdk/pull/27391#pullrequestreview-3247294844

From iklam at openjdk.org  Sat Sep 20 01:28:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 20 Sep 2025 01:28:22 GMT
Subject: RFR: 8366941: Excessive logging in serviceability tests causes timeout
Message-ID: <rJxMzMVh-sqk1_OwMIzIpm_VmMtjmdl9atbNSTeMgiU=.e4d90467-c370-4908-a3d2-3e5bed3d2c6c@github.com>

These tests use `-Xlog:all=trace` which can cause excessive output that runs very slowly, especially on Windows.
A recent change, [JDK-8362566](https://bugs.openjdk.org/browse/JDK-8362566), adds lots of output to `-Xlog:aot+map*=trace`. As a result, some of these tests are starting to timeout.

None of these tests actually require a lot of logging output. The should be fixed to use `-Xlog:all=info` instead.

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

Commit messages:
 - 8366941: Excessive logging in serviceability tests causes timeout

Changes: https://git.openjdk.org/jdk/pull/27401/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27401&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366941
  Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27401/head:pull/27401

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

From lmesnik at openjdk.org  Sat Sep 20 02:09:19 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 20 Sep 2025 02:09:19 GMT
Subject: RFR: 8366941: Excessive logging in serviceability tests causes
 timeout
In-Reply-To: <rJxMzMVh-sqk1_OwMIzIpm_VmMtjmdl9atbNSTeMgiU=.e4d90467-c370-4908-a3d2-3e5bed3d2c6c@github.com>
References: <rJxMzMVh-sqk1_OwMIzIpm_VmMtjmdl9atbNSTeMgiU=.e4d90467-c370-4908-a3d2-3e5bed3d2c6c@github.com>
Message-ID: <4PAn30z_TbjhezA3KHGAQKY7ZWAFs0g_DXl0gArFy-g=.1aaa2562-003c-4bd4-a477-bb1a4be2d057@github.com>

On Sat, 20 Sep 2025 01:20:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> These tests use `-Xlog:all=trace` which can cause excessive output that runs very slowly, especially on Windows.
> A recent change, [JDK-8362566](https://bugs.openjdk.org/browse/JDK-8362566), adds lots of output to `-Xlog:aot+map*=trace`. As a result, some of these tests are starting to timeout.
> 
> None of these tests actually require a lot of logging output. The should be fixed to use `-Xlog:all=info` instead.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27401#pullrequestreview-3247935735

From sspitsyn at openjdk.org  Sat Sep 20 04:47:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 20 Sep 2025 04:47:47 GMT
Subject: RFR: 8368159: Significant performance overhead when started with jdwp
 agent and unattached debugger
Message-ID: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>

This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown.
The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger  the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`.

Testing:
- Insure the 4X-6X slowdown is gone for application an application running millions of virtual threads and started with the JDWP agent
- Mach5 tiers 1-6 are all passed

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

Commit messages:
 - 8368159: Significant performance overhead when started with jdwp agent and unattached debugger

Changes: https://git.openjdk.org/jdk/pull/27403/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27403&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368159
  Stats: 21 lines in 3 files changed: 18 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27403.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27403/head:pull/27403

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

From sspitsyn at openjdk.org  Sat Sep 20 05:10:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 20 Sep 2025 05:10:50 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
Message-ID: <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>

> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown.
> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger  the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`.
> 
> Testing:
> - Insure the 4X-6X slowdown is gone for application an application running millions of virtual threads and started with the JDWP agent
> - Mach5 tiers 1-6 are all passed

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

  fix minimal build broken by incorrect macro usage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27403/files
  - new: https://git.openjdk.org/jdk/pull/27403/files/0f63bb17..4b0478fc

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

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

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

From sspitsyn at openjdk.org  Sat Sep 20 05:30:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 20 Sep 2025 05:30:17 GMT
Subject: RFR: 8366941: Excessive logging in serviceability tests causes
 timeout
In-Reply-To: <rJxMzMVh-sqk1_OwMIzIpm_VmMtjmdl9atbNSTeMgiU=.e4d90467-c370-4908-a3d2-3e5bed3d2c6c@github.com>
References: <rJxMzMVh-sqk1_OwMIzIpm_VmMtjmdl9atbNSTeMgiU=.e4d90467-c370-4908-a3d2-3e5bed3d2c6c@github.com>
Message-ID: <1I8dqmc1Yb5tZsdRxH3P8-0HlZhHKFbbIYUOuZQtCPM=.66a5bc53-8a38-4353-ad6c-16f32fd20482@github.com>

On Sat, 20 Sep 2025 01:20:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> These tests use `-Xlog:all=trace` which can cause excessive output that runs very slowly, especially on Windows.
> A recent change, [JDK-8362566](https://bugs.openjdk.org/browse/JDK-8362566), adds lots of output to `-Xlog:aot+map*=trace`. As a result, some of these tests are starting to timeout.
> 
> None of these tests actually require a lot of logging output. The should be fixed to use `-Xlog:all=info` instead.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27401#pullrequestreview-3248523937

From sspitsyn at openjdk.org  Sat Sep 20 05:42:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 20 Sep 2025 05:42:12 GMT
Subject: RFR: 8361955: [GCC static analyzer] libjdwp/threadControl.c
 threadControl_setPendingInterrupt error: dereference of NULL 'node'
In-Reply-To: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
References: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
Message-ID: <rSCOJ95bBcSg67PvZ7Oz1NS_H4W_wDvveeTLcZytl1c=.96cc0a50-bdb0-4171-b76d-3dd8e1d84e68@github.com>

On Thu, 18 Sep 2025 22:26:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix gcc static analyzer warning. It was introduced by [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) early last year. For the most part the fix is to revert the relevant [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) changes, except for leaving in the replacement of calling findThread() with instead calling findRunningThread().
> 
> Ran all svc tier2 and tier5 tests.

Looks reasonable.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27378#pullrequestreview-3248527406

From sspitsyn at openjdk.org  Sat Sep 20 05:58:19 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 20 Sep 2025 05:58:19 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v2]
In-Reply-To: <bkwsxILkq1tzy87KoDhJVR04gGsowxJEfsoZBhywKHg=.da83d39c-83b7-4dc9-adbd-d485503dfb19@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
 <bkwsxILkq1tzy87KoDhJVR04gGsowxJEfsoZBhywKHg=.da83d39c-83b7-4dc9-adbd-d485503dfb19@github.com>
Message-ID: <Xne3JdPa9HD0izM8WyqhQAGYPccO7jKEhHIZcuasgxE=.13fe1c01-cf7b-408c-b0c5-216a49bdf048@github.com>

On Fri, 19 Sep 2025 03:06:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.
>> 
>> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.
>
> Ioi Lam 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:
> 
>  - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
>  - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
>  - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()

Nice refactoring! Looks good.

src/hotspot/share/prims/jvm.cpp line 2259:

> 2257: //   get_klass_considering_redefinition(), or
> 2258: //   get_instance_klass_considering_redefinition()
> 2259: // These function return JvmtiThreadState::_scratch_class if the verifier

Nit: Replaces: `These function` => `These functions`

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3248533772
PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2365340212

From sspitsyn at openjdk.org  Sat Sep 20 06:01:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 20 Sep 2025 06:01:20 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <j5moEV1aWKIQF5Zhfgqu4uzBrO6V6AzSKLcUaieZvkg=.2c79d4fb-f0af-413c-83f4-bfaeb983cd57@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <j5moEV1aWKIQF5Zhfgqu4uzBrO6V6AzSKLcUaieZvkg=.2c79d4fb-f0af-413c-83f4-bfaeb983cd57@github.com>
Message-ID: <lXnpO8MT6WKQUTvY8K8WjXAqd06ScUOghgeXgxXQ54I=.3f8e5ba0-3010-40da-8e5c-3572027102f6@github.com>

On Fri, 19 Sep 2025 16:30:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix rename
>
> You might want @sspitsyn  to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays.

> @coleenp said: You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays.

Thanks. I'm looking at this update.

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3314615646

From iklam at openjdk.org  Sat Sep 20 06:43:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 20 Sep 2025 06:43:02 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v2]
In-Reply-To: <Xne3JdPa9HD0izM8WyqhQAGYPccO7jKEhHIZcuasgxE=.13fe1c01-cf7b-408c-b0c5-216a49bdf048@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
 <bkwsxILkq1tzy87KoDhJVR04gGsowxJEfsoZBhywKHg=.da83d39c-83b7-4dc9-adbd-d485503dfb19@github.com>
 <Xne3JdPa9HD0izM8WyqhQAGYPccO7jKEhHIZcuasgxE=.13fe1c01-cf7b-408c-b0c5-216a49bdf048@github.com>
Message-ID: <uUL0ajmcxmXIpx6_gOnxHEK7_oEVudpUX387dhkN58E=.95febf8f-8fe8-4edd-acf4-09cc6dbc8967@github.com>

On Sat, 20 Sep 2025 05:54:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Ioi Lam 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:
>> 
>>  - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
>>  - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
>>  - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()
>
> src/hotspot/share/prims/jvm.cpp line 2259:
> 
>> 2257: //   get_klass_considering_redefinition(), or
>> 2258: //   get_instance_klass_considering_redefinition()
>> 2259: // These function return JvmtiThreadState::_scratch_class if the verifier
> 
> Nit: Replaces: `These function` => `These functions`

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2365353625

From iklam at openjdk.org  Sat Sep 20 06:43:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 20 Sep 2025 06:43:00 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v3]
In-Reply-To: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
Message-ID: <2aaupl63WuQcMIaF_FtAudQrlhGo_fqJeF_9on4Jyz0=.0475b16d-6d9a-47e8-ad01-a091c8924398@github.com>

> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.
> 
> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.

Ioi Lam 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:

 - @sspitsyn comment -- fixed typo
 - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
 - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
 - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
 - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27303/files
  - new: https://git.openjdk.org/jdk/pull/27303/files/2504e1a6..aeec713a

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

  Stats: 5977 lines in 131 files changed: 4735 ins; 1009 del; 233 mod
  Patch: https://git.openjdk.org/jdk/pull/27303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27303/head:pull/27303

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

From coleenp at openjdk.org  Sat Sep 20 14:36:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 20 Sep 2025 14:36:17 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v3]
In-Reply-To: <2aaupl63WuQcMIaF_FtAudQrlhGo_fqJeF_9on4Jyz0=.0475b16d-6d9a-47e8-ad01-a091c8924398@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
 <2aaupl63WuQcMIaF_FtAudQrlhGo_fqJeF_9on4Jyz0=.0475b16d-6d9a-47e8-ad01-a091c8924398@github.com>
Message-ID: <3dQlxiAERWNIVA2WmoGCA6-UKilgMpDtnMLtwsEU8Tg=.34328b04-e918-49e6-bff9-88743d0ebcf9@github.com>

On Sat, 20 Sep 2025 06:43:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.
>> 
>> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.
>
> Ioi Lam 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:
> 
>  - @sspitsyn comment -- fixed typo
>  - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
>  - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
>  - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
>  - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3249059326

From iklam at openjdk.org  Sat Sep 20 17:28:21 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 20 Sep 2025 17:28:21 GMT
Subject: RFR: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition() [v2]
In-Reply-To: <Xne3JdPa9HD0izM8WyqhQAGYPccO7jKEhHIZcuasgxE=.13fe1c01-cf7b-408c-b0c5-216a49bdf048@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
 <bkwsxILkq1tzy87KoDhJVR04gGsowxJEfsoZBhywKHg=.da83d39c-83b7-4dc9-adbd-d485503dfb19@github.com>
 <Xne3JdPa9HD0izM8WyqhQAGYPccO7jKEhHIZcuasgxE=.13fe1c01-cf7b-408c-b0c5-216a49bdf048@github.com>
Message-ID: <_uDtUDGwRSizq-t31RNtjZPO-fid74m9015wvtjD58U=.de4de404-587b-48c8-9514-38dbb74616aa@github.com>

On Sat, 20 Sep 2025 05:55:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Ioi Lam 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:
>> 
>>  - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting
>>  - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition
>>  - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()
>
> Nice refactoring! Looks good.

Thanks @sspitsyn @coleenp @dholmes-ora for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27303#issuecomment-3315123837

From iklam at openjdk.org  Sat Sep 20 17:28:35 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 20 Sep 2025 17:28:35 GMT
Subject: RFR: 8366941: Excessive logging in serviceability tests causes
 timeout
In-Reply-To: <4PAn30z_TbjhezA3KHGAQKY7ZWAFs0g_DXl0gArFy-g=.1aaa2562-003c-4bd4-a477-bb1a4be2d057@github.com>
References: <rJxMzMVh-sqk1_OwMIzIpm_VmMtjmdl9atbNSTeMgiU=.e4d90467-c370-4908-a3d2-3e5bed3d2c6c@github.com>
 <4PAn30z_TbjhezA3KHGAQKY7ZWAFs0g_DXl0gArFy-g=.1aaa2562-003c-4bd4-a477-bb1a4be2d057@github.com>
Message-ID: <DREbiMDhf-Swd9FXqylc86-u0kmMIRKNid7EOiXhbok=.bbed9682-cea7-4b26-9196-74e8d4e6e741@github.com>

On Sat, 20 Sep 2025 02:06:54 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> These tests use `-Xlog:all=trace` which can cause excessive output that runs very slowly, especially on Windows.
>> A recent change, [JDK-8362566](https://bugs.openjdk.org/browse/JDK-8362566), adds lots of output to `-Xlog:aot+map*=trace`. As a result, some of these tests are starting to timeout.
>> 
>> None of these tests actually require a lot of logging output. The should be fixed to use `-Xlog:all=info` instead.
>
> Marked as reviewed by lmesnik (Reviewer).

Thanks @lmesnik @sspitsyn for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27401#issuecomment-3315123798

From iklam at openjdk.org  Sat Sep 20 17:28:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 20 Sep 2025 17:28:36 GMT
Subject: Integrated: 8366941: Excessive logging in serviceability tests causes
 timeout
In-Reply-To: <rJxMzMVh-sqk1_OwMIzIpm_VmMtjmdl9atbNSTeMgiU=.e4d90467-c370-4908-a3d2-3e5bed3d2c6c@github.com>
References: <rJxMzMVh-sqk1_OwMIzIpm_VmMtjmdl9atbNSTeMgiU=.e4d90467-c370-4908-a3d2-3e5bed3d2c6c@github.com>
Message-ID: <IAOBx8E8aRTi9wHkMhrO4GBi-RdF-8VE6vZgpi4dkYw=.dfa75a16-6fe6-4524-a572-14e2c3e53d33@github.com>

On Sat, 20 Sep 2025 01:20:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> These tests use `-Xlog:all=trace` which can cause excessive output that runs very slowly, especially on Windows.
> A recent change, [JDK-8362566](https://bugs.openjdk.org/browse/JDK-8362566), adds lots of output to `-Xlog:aot+map*=trace`. As a result, some of these tests are starting to timeout.
> 
> None of these tests actually require a lot of logging output. The should be fixed to use `-Xlog:all=info` instead.

This pull request has now been integrated.

Changeset: d21e73de
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d21e73dee3dad6332b00f5932bd266b100e9090b
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

8366941: Excessive logging in serviceability tests causes timeout

Reviewed-by: lmesnik, sspitsyn

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

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

From iklam at openjdk.org  Sat Sep 20 17:31:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 20 Sep 2025 17:31:29 GMT
Subject: Integrated: 8367719: Refactor JNI code that uses
 class_to_verify_considering_redefinition()
In-Reply-To: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
References: <mEPTtjsTK5K69L_X7wcQLIncCzPK4jKvYwR7-TkL1LI=.ad5a8a2e-d135-4040-81c3-3710b6942d9f@github.com>
Message-ID: <rvflGClybUBFxUecEKQOd7csSfnvUNVldXEMTTEDbmU=.072c9329-aeb8-4e0c-9330-459ad0d2c7d6@github.com>

On Tue, 16 Sep 2025 02:44:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls.
> 
> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`.

This pull request has now been integrated.

Changeset: cc65836d
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc65836d00de7041e7d32e7f15d98108b1ae47a0
Stats:     126 lines in 3 files changed: 16 ins; 33 del; 77 mod

8367719: Refactor JNI code that uses class_to_verify_considering_redefinition()

Reviewed-by: coleenp, dholmes, sspitsyn

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

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

From lmesnik at openjdk.org  Sat Sep 20 17:35:20 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 20 Sep 2025 17:35:20 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
Message-ID: <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>

On Sat, 20 Sep 2025 05:10:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown.
>> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger  the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`.
>> 
>> Testing:
>> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent
>> - Mach5 tiers 1-6 are all passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix minimal build broken by incorrect macro usage

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1622:

> 1620: 
> 1621: static void invalidate_jvmti_stack(JavaThread* thread) {
> 1622:   if (JvmtiExport::can_post_frame_pop() || thread->is_interp_only_mode()) {

Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only?
It is invalidated once thread switched to interp only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2365734395

From lmesnik at openjdk.org  Sat Sep 20 17:37:22 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 20 Sep 2025 17:37:22 GMT
Subject: RFR: 8361955: [GCC static analyzer] libjdwp/threadControl.c
 threadControl_setPendingInterrupt error: dereference of NULL 'node'
In-Reply-To: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
References: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
Message-ID: <c8qZGExMrSt3hJL4CLR5uNGaHAWFXwN3m6XPdVGZFmg=.fe23ef9d-a73a-4af2-90c9-f343296e408b@github.com>

On Thu, 18 Sep 2025 22:26:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix gcc static analyzer warning. It was introduced by [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) early last year. For the most part the fix is to revert the relevant [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) changes, except for leaving in the replacement of calling findThread() with instead calling findRunningThread().
> 
> Ran all svc tier2 and tier5 tests.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27378#pullrequestreview-3249164718

From wenanjian at openjdk.org  Sun Sep 21 00:50:18 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Sun, 21 Sep 2025 00:50:18 GMT
Subject: RFR: 8365732: RISC-V: implement AES CTR intrinsics [v7]
In-Reply-To: <NNd3kziE2dM8snLmu-n1vebuYQ-rXlr7u_CiEE4ETnc=.b63e1623-a720-47d4-b5d3-c17c12ea689b@github.com>
References: <mMLCDK4Ls37Ebs_3LEM4dktuylNraobBebijN1BxZwM=.30730d56-b8ca-46c9-9dc2-1ca215e66ba4@github.com>
 <CK9saRbHrBxaXya098IIqpafnO3lI90UJ1ryPwuXP14=.0ed5e960-675a-4808-a96a-eae2c4f09e07@github.com>
 <NNd3kziE2dM8snLmu-n1vebuYQ-rXlr7u_CiEE4ETnc=.b63e1623-a720-47d4-b5d3-c17c12ea689b@github.com>
Message-ID: <6-c0fA19VDBsLUwN2ewcYQ_bPSD7Zt6h5lsIOhTMGpk=.80f0aca5-601b-48dd-9c0e-c79612976da9@github.com>

On Fri, 19 Sep 2025 07:09:27 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Anjian Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into aes_ctr
>>  - fix the counter increase at limit and add test
>>  - change format
>>  - update reg use and instruction
>>  - change some name and format
>>  - delete useless Label, change L_judge_used to L_slow_loop
>>  - add Flags and fix the stubid name
>>  - RISC-V: implement AES-CTR mode intrinsics
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2667:
> 
>> 2665:     __ addi(t0, counter, 8);
>> 2666:     __ ld(tmp, Address(t0));
>> 2667:     __ rev8(tmp, tmp);
> 
> Note that `rev8` is only available under `UseZbb`. Maybe you should use `revb/revbw` instead which considers that the availability of Zbb extension.

I used the zbb and zvbb instructions in my patch?which seem not easy to replace in vector operations, and there are some optimizations when using them, so I think we may add a extension check in vm_version_riscv.cpp?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25281#discussion_r2365883933

From wenanjian at openjdk.org  Sun Sep 21 00:57:40 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Sun, 21 Sep 2025 00:57:40 GMT
Subject: RFR: 8365732: RISC-V: implement AES CTR intrinsics [v9]
In-Reply-To: <mMLCDK4Ls37Ebs_3LEM4dktuylNraobBebijN1BxZwM=.30730d56-b8ca-46c9-9dc2-1ca215e66ba4@github.com>
References: <mMLCDK4Ls37Ebs_3LEM4dktuylNraobBebijN1BxZwM=.30730d56-b8ca-46c9-9dc2-1ca215e66ba4@github.com>
Message-ID: <cDlhsc0IV-1JuE3jtTj3GNKN4dvjMDYHCRU_lgdS0C4=.1e573495-5c40-4a27-8137-d1149d643ef3@github.com>

> Hi everyone, please help review this patch which Implement the _counterMode_AESCrypt with Zvkned. On my QEMU, with Zvkned extension enabled, the tests in test/hotspot/jtreg/compiler/codegen/aes/ Passed.

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

  add zbb and zvbb check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25281/files
  - new: https://git.openjdk.org/jdk/pull/25281/files/35f82e0a..529f7cf8

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

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

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

From dholmes at openjdk.org  Mon Sep 22 05:47:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Sep 2025 05:47:20 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <7rpaBfLKYrVBVoKTcuPEpSKZR1dMmWxTuvU6UwIdKbc=.d556dd74-ede0-4588-a57c-532ed7852fb4@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

This was raised and discussed somewhere else not that long ago, but I don't recall where and it fizzled out as I recall. But I will re-raise the issues - what form should this timestamp take? Shouldn't it be configurable to allow matching with what may be presented by Unified Logging e.g. VM uptime rather than wall-clock time? The value of a timestamp on dmcd output is to allow it to be placed in chronological order relative to other output - so you need to be able to match the "timestamp" of that other output.

And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). That way users opt-in and we don't have to remember to add this for new Dcmds.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3317032230

From mbaesken at openjdk.org  Mon Sep 22 07:03:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 22 Sep 2025 07:03:17 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <gLaZrGgoJbk7_st5N8kR1vtHytGn_Mn8xDR5SmaS950=.a4df92f3-6b27-446c-9a13-226176eb9750@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

Hi Alexey, thanks for approving !

>  So let's wait for some feedback on libsyslookup .

Any updates on the libsyslookup topic ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3317248191

From jsjolen at openjdk.org  Mon Sep 22 07:19:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 22 Sep 2025 07:19:40 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v6]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <_-rP9r52cIQ72jHM6FkynToLo0rZ7S4CUmlNvCoEvTU=.32262b01-b691-4863-9d87-db142ddcf92f@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/6f47508b..0f60034c

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

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

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

From jsjolen at openjdk.org  Mon Sep 22 08:02:57 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 22 Sep 2025 08:02:57 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/operands-again' into operands-again
 - Fix BSM naming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/0f60034c..d8624f09

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

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

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

From jsjolen at openjdk.org  Mon Sep 22 08:03:00 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 22 Sep 2025 08:03:00 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <j5moEV1aWKIQF5Zhfgqu4uzBrO6V6AzSKLcUaieZvkg=.2c79d4fb-f0af-413c-83f4-bfaeb983cd57@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <j5moEV1aWKIQF5Zhfgqu4uzBrO6V6AzSKLcUaieZvkg=.2c79d4fb-f0af-413c-83f4-bfaeb983cd57@github.com>
Message-ID: <hy-jDgRmm7Y3bY_1kAfJ00JDgCIvJbpMllXYCuZl2a8=.a55cce6e-a8d7-4477-ad40-9a362de24ce1@github.com>

On Fri, 19 Sep 2025 16:30:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix rename
>
> You might want @sspitsyn  to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays.

@coleenp, I can move the new classes to its own file, but let's wait until all other reviewing is done (makes it less confusing).

Thanks David for finding all of the style issues. I had a go at removing any mention of 'operands' in the sense of  "the BSM attribute of a constant pool".

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3317438712

From mdoerr at openjdk.org  Mon Sep 22 09:28:52 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 Sep 2025 09:28:52 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <BkK2R8rxY9PzEt72KHMr8DN95MVqkaAVJcGctyaMvVM=.6549f83d-e513-4485-bd76-c40b1fcbc9e5@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <BkK2R8rxY9PzEt72KHMr8DN95MVqkaAVJcGctyaMvVM=.6549f83d-e513-4485-bd76-c40b1fcbc9e5@github.com>
Message-ID: <mPWTkcvbSNSLyESDpLFdsdB4E9dFR-98qaDyAXcK1nI=.78780a4d-43d3-4987-b023-2db70a6c247c@github.com>

On Fri, 19 Sep 2025 09:09:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I've pinged Maurizio about libsyslookup; let's hear what he says first.

@JornVernee: You may also want to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3317784399

From coffeys at openjdk.org  Mon Sep 22 11:24:34 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 22 Sep 2025 11:24:34 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <K_RN1gRkQ5FN2jKz8X2Yx3bHB9YJBTaxqPV06LfCIPA=.00fc2e19-4c30-4c62-88f2-5e98071bd407@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

The Thread.print dcmd already uses the yyyy-MM-dd HH:mm:ss format but yes, having all timestamps in a consistent format and time zone is useful for log comparisons. 

I'd second the global dcmd flag suggestion which would allow the option of the timestamp(on or off). Some commands should have timestamp on by default though. Those where output is sensitive to the time that the command was issued. e.g. 
Thread dumps
...and as per JBS suggestions, other examples include: (but not limited to)
GC.finalizer_info
GC.heap_info

Looking at such data output in isolation with the absence of timestamps makes it far less valuable IMO, especially when one wants to compare it to application logs, GC logs etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3318375894

From kevinw at openjdk.org  Mon Sep 22 11:53:31 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 22 Sep 2025 11:53:31 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <62myjO2d32Qn7JlSXzrPnBQTLDKQ47iuCLGDJ3kdN5Y=.baaca9de-baec-4bd9-9a6b-5e86e1910cce@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

I think it should be clearer what the benefit is, who the users are.

In a remote support situation where the the user is gathering info, then timestamps are good.
Running "date; jcmd ... " is an alternative.


An optional global timestamp setting could be in the Jcmd launcher, which would mean it doesn't have to be implemented in each native diagnostic command impl.
i.e. a jcmd option before the PID.

jcmd -T PID command...  (or whatever option)
jcmd -T -f commands.txt  ... could that print a timestamp before every inidvidual command?

That might be straightforward, but then you can get double timestamps if the jcmd implementation already prints one (so do you remove the timestamp from Thread.print if the jcmd launcher starts printing it?)

Also complicated for some to commands enable a timestamp by default, the jcmd launcher does not know anything about command implementations.
So maybe it needs some common code on the native side.

Do we print a timestamp if the command is not recognised?

Lots of questions. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3318507194

From syan at openjdk.org  Mon Sep 22 12:28:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Sep 2025 12:28:53 GMT
Subject: RFR: 8368094: Fix problem list errors
In-Reply-To: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
References: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
Message-ID: <RCGISTPg900LQasGnLhygbDA0bcX00X4BtmiyHE5Ong=.4eb76cde-6707-483f-9991-aeadb5f8be5d@github.com>

On Fri, 19 Sep 2025 12:38:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I am trying to add `--verify-excludes` to all jtreg runs. This new flag will let jtreg catch (at least some) mistakes in problem lists. There are some technical hurdles remaining to add this option, but in the meantime I thought I could at least fix those issues I have found so far. This is not exhaustive, I am sure there are more issues that will be discovered, but these are at least real errors that can be fixed.
> 
> For reviewing, I recommend looking at the individual commits where I give a reason for each change.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27391#pullrequestreview-3252410885

From ihse at openjdk.org  Mon Sep 22 13:40:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Sep 2025 13:40:07 GMT
Subject: Integrated: 8368094: Fix problem list errors
In-Reply-To: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
References: <dOEeAh8FTX6iFUxb0M9HckH1un59VMUASxphW6v30bQ=.0aebb2b2-27cd-4b66-b0ce-928eecf971ff@github.com>
Message-ID: <lwhF7pZ9rDlBB_oNYlwOnWUnBQJeD0gbujwQWwVDIks=.18588db4-8683-4f6a-ab7f-ebd85506253a@github.com>

On Fri, 19 Sep 2025 12:38:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I am trying to add `--verify-excludes` to all jtreg runs. This new flag will let jtreg catch (at least some) mistakes in problem lists. There are some technical hurdles remaining to add this option, but in the meantime I thought I could at least fix those issues I have found so far. This is not exhaustive, I am sure there are more issues that will be discovered, but these are at least real errors that can be fixed.
> 
> For reviewing, I recommend looking at the individual commits where I give a reason for each change.

This pull request has now been integrated.

Changeset: ca182912
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca182912a305e1e226d97d9613c7baf8a3d22780
Stats:     26 lines in 5 files changed: 2 ins; 19 del; 5 mod

8368094: Fix problem list errors

Reviewed-by: dholmes, dcubed, syan

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

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

From jvernee at openjdk.org  Mon Sep 22 15:06:09 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 22 Sep 2025 15:06:09 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
 <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
 <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>
Message-ID: <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>

On Fri, 19 Sep 2025 09:08:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>  but it is not used

It is not used by the library itself, but we do dynamic `dlsym` calls on this library when a user tries to look up a symbol through `Linker.nativeLinker().defaultLookup().find(...)`. This is supposed to be able to find symbols from 'the standard library' which is an unspecified platform specific set of symbols. We link against `libdl` so that we can find symbols in that library as well (since `dlsym` recurses into a library's dependencies when looking up a symbol). We don't have a comprehensive test which tests that a certain set of symbols is available. Trying to look up a symbol from `libdl` might give a false positive if the symbol happens to be pulled in by another library that `libsyslookup` depends on, so testing this is unreliable.

Either way, I think we want to keep linking against `libdl` so that it keeps being a dependency of the `libsyslookup` library.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2368874988

From mbaesken at openjdk.org  Mon Sep 22 15:32:27 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 22 Sep 2025 15:32:27 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

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

  libsyslookup - bring back LIBDL (comment JornVernee)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27358/files
  - new: https://git.openjdk.org/jdk/pull/27358/files/7c102d5f..54c0339e

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

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

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

From mdoerr at openjdk.org  Mon Sep 22 15:45:44 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 Sep 2025 15:45:44 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>
Message-ID: <Q7-drd7xo80YV7jKpuZCW6eDR2KgcPuPOchY5fi1Aa4=.f5fb5c35-6015-40d0-8133-dbe1366d7db1@github.com>

On Mon, 22 Sep 2025 15:32:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   libsyslookup - bring back LIBDL (comment JornVernee)

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3253643189

From erikj at openjdk.org  Mon Sep 22 16:36:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 Sep 2025 16:36:57 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
 <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
 <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>
 <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>
Message-ID: <fPcjhpd8fCqQXE1yQzBRGNLyBF1WRFxnECiFl2CB79Q=.92dcbd06-31c1-4f19-a5c3-ff67addee46d@github.com>

On Mon, 22 Sep 2025 15:00:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @mcimadamore Can you help us here? libsyslookup has a dependency to libdl, but it is not used. Can we remove that from the linker command line, or would it somehow break libsyslookup? (I have just a very  fuzzy idea of the point of this library.) If we try to remove it, what tests do we need to run to make sure we do not break anything?
>
>>  but it is not used
> 
> It is not used by the library itself, but we do dynamic `dlsym` calls on this library when a user tries to look up a symbol through `Linker.nativeLinker().defaultLookup().find(...)`. This is supposed to be able to find symbols from 'the standard library' which is an unspecified platform specific set of symbols. We link against `libdl` so that we can find symbols in that library as well (since `dlsym` recurses into a library's dependencies when looking up a symbol). We don't have a comprehensive test which tests that a certain set of symbols is available. Trying to look up a symbol from `libdl` might give a false positive if the symbol happens to be pulled in by another library that `libsyslookup` depends on, so testing this is unreliable.
> 
> Either way, I think we want to keep linking against `libdl` so that it keeps being a dependency of the `libsyslookup` library, to guarantee that `libdl` symbols will be findable.

These sounds convoluted enough to warrant a comment explaining this in the makefile to avoid accidents in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2369325183

From cjplummer at openjdk.org  Mon Sep 22 17:21:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Sep 2025 17:21:51 GMT
Subject: RFR: 8361955: [GCC static analyzer] libjdwp/threadControl.c
 threadControl_setPendingInterrupt error: dereference of NULL 'node'
In-Reply-To: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
References: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
Message-ID: <gqvzVdbpNaMKE9h9-2byCRoJDPyVSNMrL8ykvSJwXbo=.71551481-ed82-40ce-bbc2-d4a56c841106@github.com>

On Thu, 18 Sep 2025 22:26:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix gcc static analyzer warning. It was introduced by [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) early last year. For the most part the fix is to revert the relevant [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) changes, except for leaving in the replacement of calling findThread() with instead calling findRunningThread().
> 
> Ran all svc tier2 and tier5 tests.

Thank you for the reviews David, Serguei, and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/27378#issuecomment-3320296818

From cjplummer at openjdk.org  Mon Sep 22 17:25:41 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Sep 2025 17:25:41 GMT
Subject: Integrated: 8361955: [GCC static analyzer] libjdwp/threadControl.c
 threadControl_setPendingInterrupt error: dereference of NULL 'node'
In-Reply-To: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
References: <fJxskxkfRvj7N25rgO_BGh_84wARx1hl2NVEjUUH-PU=.77b4cd7c-7109-4aa7-af64-4032320d3cd1@github.com>
Message-ID: <nBUsx7QsJt4ty0uUHzNIwNZAVBx0Whm_WPCmJqbACGY=.9c99068d-738e-465c-942f-1935700c2c08@github.com>

On Thu, 18 Sep 2025 22:26:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix gcc static analyzer warning. It was introduced by [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) early last year. For the most part the fix is to revert the relevant [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) changes, except for leaving in the replacement of calling findThread() with instead calling findRunningThread().
> 
> Ran all svc tier2 and tier5 tests.

This pull request has now been integrated.

Changeset: c3aaa875
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3aaa8751acfd795207f1a509b6e170e6a753c69
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8361955: [GCC static analyzer] libjdwp/threadControl.c threadControl_setPendingInterrupt error: dereference of NULL 'node'

Reviewed-by: dholmes, sspitsyn, lmesnik

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

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

From schernyshev at openjdk.org  Mon Sep 22 20:06:10 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 22 Sep 2025 20:06:10 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
Message-ID: <yMfh1521iPYCjmqE1C4piYJw3RA_pC6TBRISWjSKGeA=.45f87bac-d7b4-42b9-b844-d56ccfa4c8b4@github.com>

On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments

@turbanoff @dholmes-ora @larry-cable Could you please take a look at this?

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3321272195

From ihse at openjdk.org  Mon Sep 22 21:06:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Sep 2025 21:06:51 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
 <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
 <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>
 <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>
Message-ID: <TUcNVWuAvwAaqlG0qSMa5hLHFjJsJBvp5nWifsPHTbI=.b4197f75-078a-4789-b8e9-382394b44a75@github.com>

On Mon, 22 Sep 2025 15:00:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @mcimadamore Can you help us here? libsyslookup has a dependency to libdl, but it is not used. Can we remove that from the linker command line, or would it somehow break libsyslookup? (I have just a very  fuzzy idea of the point of this library.) If we try to remove it, what tests do we need to run to make sure we do not break anything?
>
>>  but it is not used
> 
> It is not used by the library itself, but we do dynamic `dlsym` calls on this library when a user tries to look up a symbol through `Linker.nativeLinker().defaultLookup().find(...)`. This is supposed to be able to find symbols from 'the standard library' which is an unspecified platform specific set of symbols. We link against `libdl` so that we can find symbols in that library as well (since `dlsym` recurses into a library's dependencies when looking up a symbol). We don't have a comprehensive test which tests that a certain set of symbols is available. Trying to look up a symbol from `libdl` might give a false positive if the symbol happens to be pulled in by another library that `libsyslookup` depends on, so testing this is unreliable.
> 
> Either way, I think we want to keep linking against `libdl` so that it keeps being a dependency of the `libsyslookup` library, to guarantee that `libdl` symbols will be findable.

@JornVernee Thanks! You confirmed basically what I suspected.

@MBaesken Can you revert your changes to `libsyslookup`, and add a comment summarizing Jorn's description above, that it is imperative that we keep linking with libdl even if it seems unused by the library.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2370302658

From cjplummer at openjdk.org  Mon Sep 22 21:16:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Sep 2025 21:16:45 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
 <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>
Message-ID: <Wxt86Eg4f_h4ifrWKnO-LyGJ_sM64nny4spo6CoEnyk=.92cf116c-1c97-46d8-aa64-19d94812f0ba@github.com>

On Sat, 20 Sep 2025 17:32:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix minimal build broken by incorrect macro usage
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1622:
> 
>> 1620: 
>> 1621: static void invalidate_jvmti_stack(JavaThread* thread) {
>> 1622:   if (JvmtiExport::can_post_frame_pop() || thread->is_interp_only_mode()) {
> 
> Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only?
> It is invalidated once thread switched to interp only.

It seems odd to me that a method called `invalidate_jvmti_stack()` sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2370319721

From duke at openjdk.org  Mon Sep 22 22:55:44 2025
From: duke at openjdk.org (Larry Cable)
Date: Mon, 22 Sep 2025 22:55:44 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
Message-ID: <TdAgdLQPEVK9Hbb9FwgmP1pheoSDioo-imSFUjHw_s4=.55f6b833-b64d-426f-961f-256037c75e82@github.com>

On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments

will do!

On 9/22/25 1:04 PM, Sergey Chernyshev wrote:
> *sercher* left a comment (openjdk/jdk#25824) 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/25824*issuecomment-3321272195__;Iw!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810uaE86kA$>
>
> @turbanoff 
> <https://urldefense.com/v3/__https://github.com/turbanoff__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2812g3XS-WA$> 
> @dholmes-ora 
> <https://urldefense.com/v3/__https://github.com/dholmes-ora__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2813-Ly68vg$> 
> @larry-cable 
> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810J2TUJ4w$> 
> Could you please take a look at this?
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/25824*issuecomment-3321272195__;Iw!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810uaE86kA$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67VRW3666Z2O5P7IMJT3UBI3LAVCNFSM6AAAAAB7MZH7WGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRRGI3TEMJZGU__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810UmUzuKQ$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------clQK6hO50V7lxYIyzZn4ddE5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    will do!<br>
    <br>
    <div class="moz-cite-prefix">On 9/22/25 1:04 PM, Sergey Chernyshev
      wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <div style="display: flex; flex-wrap: wrap; white-space: pre-wrap; align-items: center; "><img height="20" width="20" style="border-radius:50%; margin-right: 4px;" decoding="async" src="https://avatars.githubusercontent.com/u/6394632?s=20&amp;v=4" moz-do-not-send="true"><strong>sercher</strong> left a comment <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/25824*issuecomment-3321272195__;Iw!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810uaE86kA$" moz-do-not-send="true">(openjdk/jdk#25824)</a></div>
      <p dir="auto"><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/turbanoff/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/turbanoff__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2812g3XS-WA$" ***@***.***</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/dholmes-ora/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/dholmes-ora__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2813-Ly68vg$" ***@***.***</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/larry-cable/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense
 .com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810J2TUJ4w$" ***@***.***</a> Could you please take
        a look at this?</p>
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/25824*issuecomment-3321272195__;Iw!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810uaE86kA$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67VRW3666Z2O5P7IMJT3UBI3LAVCNFSM6AAAAAB7MZH7WGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRRGI3TEMJZGU__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810UmUzuKQ$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67RY5B2DW4ALWX3PHZ33UBI3LA5CNFSM6AAAAAB7MZH7WGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTWF62LYG.gif" height="1" width="1" alt="" moz-do-not-send="true"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/25824/c3321272195</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/25824#issuecomment-3321272195",
"url": "https://github.com/openjdk/jdk/pull/25824#issuecomment-3321272195",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------clQK6hO50V7lxYIyzZn4ddE5--

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3321771506

From dholmes at openjdk.org  Tue Sep 23 02:51:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Sep 2025 02:51:37 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
Message-ID: <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>

On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments

This seems reasonable but I am far from expert in this area of macOS, nor in the Java side of this code. Serviceability need to take a good look at this.

I few minor nits below.

Thanks

src/hotspot/os/bsd/os_bsd.cpp line 893:

> 891: //
> 892: static const char VAR_FOLDERS[] = "/var/folders/";
> 893: int os::Bsd::get_user_tmp_dir_macos(const char* user, int vmid, char *output_path, int output_size /* = PATH_MAX */) {

Suggestion:

int os::Bsd::get_user_tmp_dir_macos(const char* user, int vmid, char* output_path, int output_size) {

src/hotspot/os/bsd/os_bsd.cpp line 912:

> 910:       // absolute path to the bucket
> 911:       char bucket[PATH_MAX];
> 912:       int b = snprintf(bucket, PATH_MAX, "%s%s/", VAR_FOLDERS, bucket_de->d_name);

Suggestion:

      int b = os::snprintf(bucket, PATH_MAX, "%s%s/", VAR_FOLDERS, bucket_de->d_name);

Just for clarity

src/hotspot/os/bsd/os_bsd.cpp line 936:

> 934:         //
> 935:         char perfdata_path[PATH_MAX];
> 936:         int p = snprintf(perfdata_path, PATH_MAX, "%s%s/T/%s_%s/", bucket, subbucket_de->d_name, PERFDATA_NAME, user);

Suggestion:

        int p = os::snprintf(perfdata_path, PATH_MAX, "%s%s/T/%s_%s/", bucket, subbucket_de->d_name, PERFDATA_NAME, user);

src/hotspot/os/bsd/os_bsd.cpp line 947:

> 945: 
> 946:           // the return value of snprintf is not checked for the second time
> 947:           return snprintf(output_path, output_size, "%s%s/T", bucket, subbucket_de->d_name);

Suggestion:

          return os::snprintf(output_path, output_size, "%s%s/T", bucket, subbucket_de->d_name);

src/hotspot/os/bsd/os_bsd.hpp line 68:

> 66: 
> 67: #ifdef __APPLE__
> 68:   static int get_user_tmp_dir_macos(const char* user, int vmid, char *output_buffer, int buffer_size /* = PATH_MAX */);

Suggestion:

  static int get_user_tmp_dir_macos(const char* user, int vmid, char* output_buffer, int buffer_size);

The buffer size is up to the caller.

src/hotspot/os/posix/perfMemory_posix.cpp line 1180:

> 1178:   int nspid = LINUX_ONLY(os::Linux::get_namespace_pid(vmid)) NOT_LINUX(-1);
> 1179:   const char* luser = NOT_MACOS(get_user_name(vmid, &nspid, CHECK))
> 1180:     MACOS_ONLY(get_user_name(os::Bsd::get_process_uid(vmid)));

Suggestion:

  const char* luser = NOT_MACOS(get_user_name(vmid, &nspid, CHECK))
                      MACOS_ONLY(get_user_name(os::Bsd::get_process_uid(vmid)));

src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 31:

> 29: import com.sun.tools.attach.spi.AttachProvider;
> 30: 
> 31: import sun.jvmstat.PlatformSupport;

This is convenient but I'm not sure it is appropriate. Need the serviceability folk to comment.

src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 49:

> 47:     // the latter can be changed by the user.
> 48:     // Any changes to this needs to be synchronized with HotSpot.
> 49:     private static final String tmpdir;

So we can't cache this any more?

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

PR Review: https://git.openjdk.org/jdk/pull/25824#pullrequestreview-3255835341
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370839037
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370840143
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370841710
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370842039
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370844530
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370846681
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370851193
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370853656

From sspitsyn at openjdk.org  Tue Sep 23 04:26:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Sep 2025 04:26:29 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
Message-ID: <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>

On Mon, 22 Sep 2025 08:02:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>  - Fix BSM naming

src/hotspot/share/oops/constantPool.hpp line 116:

> 114:     return _argument_count;
> 115:   }
> 116:   int argument(int n) const {

Q: Why was the function name changed?

src/hotspot/share/oops/constantPool.hpp line 139:

> 137:     int _cur_offset;
> 138:     // Current unused offset into BSMAEs bsm-data array
> 139:     int _cur_array;

Nit: I'd suggest to rename this to something like `_cur_bsm_entry`.

src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 440:

> 438:   int append_bsm_entry(const constantPoolHandle& scratch_cp, int scratch_bootstrap_spec_index,
> 439:     constantPoolHandle *merge_cp_p, int *merge_cp_length_p);
> 440:   void finalize_bsmentries_merge(const constantPoolHandle& merge_cp, TRAPS);

Nit: A suggestion to rename: `finalize_bsmentries_merge` => `finalize_bsm_entries_merge`

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 95:

> 93:     Type bsmaetype = db.lookupType("BSMAttributeEntries");
> 94:     bsmaentries_offsets = bsmaetype.getAddressField("_offsets");
> 95:     bsmaentries_bootstrap_methods = bsmaetype.getAddressField("_bootstrap_methods");

Nit: A suggestion to rename:
  `bsmaentries` => `bsma_entries` or `bsm_entries`
  `bsmaetype`   => `bsma_type` or `bsm_type`
  `bsmaentries_offsets` => `bsma_entries_offsets` or `bsm_entries_offsets`
  `bsmaentries_bootstrap_methods` => `bsma_entries_bootstrap_methods` or `bsm_entries_bootstrap_methods`

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 122:

> 120:   private static long bsmaentries; // Offset in the constantpool where the BSMAEntries are found
> 121:   private static AddressField bsmaentries_offsets;
> 122:   private static AddressField bsmaentries_bootstrap_methods;

Nit: Same renaming suggestion as above.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 482:

> 480:     int basePos = offs.at(bsmIndex);
> 481:     int argv = basePos + INDY_ARGV_OFFSET;
> 482:     int argc = getBootstrapMethodArgsCount(bsmIndex);

Nit: Consider to make it shorter:
  `getBootstrapMethods` => `getBSMs`
  `getBootstrapMethodArgsCount` => `getBSMArgsCount`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371074352
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371075707
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371078749
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371084318
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371084929
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371087738

From sspitsyn at openjdk.org  Tue Sep 23 04:33:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Sep 2025 04:33:42 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
Message-ID: <TEilMfBj4quy7wrgYjqc1TsFWE6EkBdpYIrN6wj5Gkc=.b808b3fc-fc87-4208-b853-bcd926925a32@github.com>

On Mon, 22 Sep 2025 08:02:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>  - Fix BSM naming

src/hotspot/share/oops/constantPool.hpp line 128:

> 126: 
> 127: // The BSMAttributeEntries stores the state of the BootstrapMethods attribute.
> 128: class BSMAttributeEntries {

Nit: I'm thinking if it would make sense to rename it to `BSMEntries`.
Then we could rename this as well: `BSMAttributeEntry` => `BSMEntry`.
It feels like it will increase the readability as it is already clear that `BSMEntry` is about `BSM` attributes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371104606

From sspitsyn at openjdk.org  Tue Sep 23 04:42:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Sep 2025 04:42:43 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
Message-ID: <XTgUz2IhjWOAI6tkuEWw8brlARaDFZPJF6J-MQ_fruI=.30224907-930e-4891-a116-5ca7a02640b3@github.com>

On Mon, 22 Sep 2025 08:02:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>  - Fix BSM naming

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 393:

> 391: void JvmtiClassFileReconstituter::write_bootstrapmethod_attribute() {
> 392:   write_attribute_name_index("BootstrapMethods");
> 393:   u4 length = sizeof(u2) + // Size of num_bootstrap_methods

Nit: The comment update is confusing. Should it remain as it was? :

   u4 length = sizeof(u2); // num_bootstrap_methods

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371115648

From mbaesken at openjdk.org  Tue Sep 23 08:10:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 08:10:03 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

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

  Add comment regarding LIBSYSLOOKUP and LIBDL

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27358/files
  - new: https://git.openjdk.org/jdk/pull/27358/files/54c0339e..8d6fee5b

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

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

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

From mbaesken at openjdk.org  Tue Sep 23 08:10:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 08:10:04 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>
Message-ID: <7c8YuMaalOW6frwsrdVM3C6EK2UAKHQpPDMUukqKhfo=.60750900-9cd1-46d9-97fe-abcef874edfb@github.com>

On Mon, 22 Sep 2025 15:32:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   libsyslookup - bring back LIBDL (comment JornVernee)

I added a comment regarding LIBSYSLOOKUP / LIBDL .

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3322859888

From duke at openjdk.org  Tue Sep 23 09:00:13 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Tue, 23 Sep 2025 09:00:13 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <UhtkOWgYWt4oM9gHx9by0OcEeCCeuRTBuo6Kn7HJHK0=.a9c34983-6a0f-49b5-8316-249ce421164c@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

Speaking of having "print a timestamp" as a global flag. Placing be the flag early for the launcher, before `pid | main class` gives some benefits:
* we can document the flag in the general documentation "jcmd -h"
* we could place the timestamp on the same line with PID printed by launcher.

$ jcmd -T ${PID} VM.info
12345: 2025-01-01 23:59:59
. . .

Is there any issues to that?

On the other hand, I see dcmd implements a special rule to handle "-h", "-help", and "--help" flags placed at the end of `jcmd` arguments list. We could allow the new "timestamp" flag to be passed past the `jcmd PID command`, Process the flag in `DCmdFactory` and pass the boolean down to a concrete `DCmd` instance.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3323026694

From kevinw at openjdk.org  Tue Sep 23 09:48:25 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Sep 2025 09:48:25 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <tid__B3lWtwKY09Rd01S0KeK_wxzkI81C3TFjvh0HwQ=.e8710c78-2ba3-4f34-946a-0e203a5def40@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

Hi, that sounds promising.  
I do think we should state the benefit of having this (we don't expect much latency as this is a local attach).

Passing something on to the native impl is interesting - then, if the jcmd launcher prints pid:, then timestamp on a newline, can Thread.print find out a timestamp is already printed, and not duplicate it?

3975026:
2025-09-23 10:31:54
Full thread dump ...

Or, should Thread.print stop printing a timestamp, and rely on the launcher to do it.  That would avoid that communication, but would mean we have to default to timestamps ON, or Thread.print output format will change (which is not completely illegal, but will no doubt surprise some people/scripts).  Or, have the two sides communicate and Thread.print prints the timestamp, if it has not been shown already.  Nothing there is as simple as we'd like. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3323188843

From alanb at openjdk.org  Tue Sep 23 09:51:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Sep 2025 09:51:32 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <8duI9y23ZbCVBCnXhbXHm5FHbLzQCXoQr_4f2zhzJic=.154c446d-c3fb-4a32-a88f-0ef0dd76fedf@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

It might be useful for @larry-cable to comment on this too. I think he's exploring some of these command serving up JSON rather than plain text. Any "infrastructure" that print a plain text timestamp could mess that up.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3323199390

From stuefe at openjdk.org  Tue Sep 23 09:59:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 Sep 2025 09:59:53 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <oM68Gs7U2PdAcJJYitPXlYAALeULpk6Rx5U2uZx54yA=.e372d960-07b3-498a-89d3-14bfc655f3c6@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

Piling on...

I think this feature would be useful. I wished for this more often than not.

I think the printing should be done on the server side, not on the client side (be it a `date` before the invocation of jcmd, or jcmd itself printing the date), since the timestamp on the server side may be different than that of the client jcmd.

I would prefer a timestamp in the UL "time" decoration format: Full ISO-8601, including timezone offset. See https://openjdk.org/jeps/158 . That would also keep in line with gc logs etc.

I am not sure we need a specific option to disable or enable this. Who would want to disable this feature?

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3323234159

From aivanov at openjdk.org  Tue Sep 23 11:17:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Sep 2025 11:17:56 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
Message-ID: <XFM7yly3EDiG3i3Z_pAHelxL8XI1my_uBlw2mu2DMrc=.7b2bb9e8-7cbc-419f-b985-66342e0815b8@github.com>

On Tue, 23 Sep 2025 08:10:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment regarding LIBSYSLOOKUP and LIBDL

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3257437167

From ihse at openjdk.org  Tue Sep 23 11:43:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Sep 2025 11:43:19 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
Message-ID: <dkLp41QrXmZs4ZEbcm9TG7YKYqdOXk76uPBaiwWGe-M=.2d4de0e9-57c2-4c8a-a267-e3089a8cc749@github.com>

On Tue, 23 Sep 2025 08:10:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment regarding LIBSYSLOOKUP and LIBDL

make/modules/java.base/Lib.gmk line 199:

> 197:       CXXFLAGS := -std=c++17, \
> 198:       DISABLED_WARNINGS_gcc := unused-variable, \
> 199:       LIBS_linux := $(LIBDL) $(LIBM), \

You need to restore the libdl dependency as well, not just document why it's needed. ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2372023487

From mbaesken at openjdk.org  Tue Sep 23 11:56:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 11:56:49 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <dkLp41QrXmZs4ZEbcm9TG7YKYqdOXk76uPBaiwWGe-M=.2d4de0e9-57c2-4c8a-a267-e3089a8cc749@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
 <dkLp41QrXmZs4ZEbcm9TG7YKYqdOXk76uPBaiwWGe-M=.2d4de0e9-57c2-4c8a-a267-e3089a8cc749@github.com>
Message-ID: <7Jh6JTRECBsbB03-JqBSP8CkoFVNUnoPjdXUdtxFNaw=.9e01fbff-483f-4c3b-adb1-a5d050744b6a@github.com>

On Tue, 23 Sep 2025 11:40:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment regarding LIBSYSLOOKUP and LIBDL
>
> make/modules/java.base/Lib.gmk line 199:
> 
>> 197:       CXXFLAGS := -std=c++17, \
>> 198:       DISABLED_WARNINGS_gcc := unused-variable, \
>> 199:       LIBS_linux := $(LIBDL) $(LIBM), \
> 
> You need to restore the libdl dependency as well, not just document why it's needed. ;-)

That's another build  ( BUILD_LIBSIMD_SORT ). Not our special  one (syslookup).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2372055345

From fbredberg at openjdk.org  Tue Sep 23 12:17:28 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 23 Sep 2025 12:17:28 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
Message-ID: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>

This is a general cleanup after removing `LockingMode` related code.
It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
It includes:
- Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
- Removing or rewriting comments, arguments or functions that are related to displaced headers.
- Remove "always true" parameter from `MonitorExitStub`.
- Re-type/name metadata in `BasicLock`.

Tier1-5 passes okay on supported platforms.

All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

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

Commit messages:
 - Merge branch 'master' into 8365191_lockingmode_cleanup
 - 8365191: Cleanup after removing LockingMode related code

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

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

From aivanov at openjdk.org  Tue Sep 23 12:34:46 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Sep 2025 12:34:46 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <7Jh6JTRECBsbB03-JqBSP8CkoFVNUnoPjdXUdtxFNaw=.9e01fbff-483f-4c3b-adb1-a5d050744b6a@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
 <dkLp41QrXmZs4ZEbcm9TG7YKYqdOXk76uPBaiwWGe-M=.2d4de0e9-57c2-4c8a-a267-e3089a8cc749@github.com>
 <7Jh6JTRECBsbB03-JqBSP8CkoFVNUnoPjdXUdtxFNaw=.9e01fbff-483f-4c3b-adb1-a5d050744b6a@github.com>
Message-ID: <QqfdUOiga612AGpZNhc6bJZgiOIRHd-8Sm7UbC-nFVw=.842408aa-1ab7-4e42-a981-08aa5dcfcca1@github.com>

On Tue, 23 Sep 2025 11:53:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 199:
>> 
>>> 197:       CXXFLAGS := -std=c++17, \
>>> 198:       DISABLED_WARNINGS_gcc := unused-variable, \
>>> 199:       LIBS_linux := $(LIBDL) $(LIBM), \
>> 
>> You need to restore the libdl dependency as well, not just document why it's needed. ;-)
>
> That's another build  ( BUILD_LIBSIMD_SORT ). Not our special  one (syslookup).

Yes, it looks confusing in the diffs. You have to expand the unchanged lines to see it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2372166387

From fbredberg at openjdk.org  Tue Sep 23 13:16:30 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 23 Sep 2025 13:16:30 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <ZokiucWezjf8UFF8LkTV2xUKQosC2Y4iaaUo-sJ6XfA=.dcc4c65e-f1d1-44ae-b029-233d9eb94c38@github.com>

On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

@bulasevich, @TheRealMDoerr, @RealFYang, @offamitkumar
I've run rudimentary tests using QEMU, but it would be nice if you guys (or any of your friends) could take it for a spin on real hardware. Thanks in advance.

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

PR Comment: https://git.openjdk.org/jdk/pull/27448#issuecomment-3323970915

From ihse at openjdk.org  Tue Sep 23 13:53:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Sep 2025 13:53:15 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
Message-ID: <8azN1bEI1nk3bHz_5oaNXn48qJ9oYiTRl870YXy3yT8=.345c467e-9f9a-448b-ab75-5ae8c2df1770@github.com>

On Tue, 23 Sep 2025 08:10:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment regarding LIBSYSLOOKUP and LIBDL

I see. Sorry I misread. Then this looks good!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3258138148

From mdoerr at openjdk.org  Tue Sep 23 13:59:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 23 Sep 2025 13:59:43 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <CkKxS8kyz-KGo94A38siWVDB1A7RWRB0V740YkjaWec=.9d0bc51f-9a20-4e8b-b98a-aa772b44a66d@github.com>

On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

PPC64 and hotspot/share/c1 changes LGTM. Thanks for cleaning it up!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3258165227

From kevinw at openjdk.org  Tue Sep 23 14:27:40 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Sep 2025 14:27:40 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
Message-ID: <WCa4dCTYFTTzGZtzK25Nk45fclccvMG3vU_KpivOrig=.c5785f6c-3b08-4004-8b6a-66db33853740@github.com>

On Tue, 16 Sep 2025 08:22:10 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - nn
>  - comment and rename

Thanks for the additional info.

If I ignore what's said so far and start again, I see the following...  (anyone should feel free to correct, we aren't in this area every day!...)

hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5)

          print_error("address conflict @ 0x%lx (existing map size = %ld, size = %ld, flags = %d)\n",
                        target_vaddr, existing_map->memsz, lib_php->p_memsz, lib_php->p_flags);

core has no mapping at exactly 0x7fa9ff0e4440 but has:

  Start                 End               Page Offset
  0x00007fa9ff0db000  0x00007fa9ff0e4000  0x0000000000000000 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so  (0x9000 size) 0x841c rounded up
  0x00007fa9ff0e4000  0x00007fa9ff0fd000  0x0000000000000008 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so (0x19000 size) the existing map size from the error
  

The error is having a size 0x17c30 mapping that should go at 0x00007fa9ff0e4000
That is the second LOAD phdr from libjimage.

The check which has been working for gcc builds:
ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size)

102400 	= 0x19000 is mem size, page size aligned. The core has a mapping of this size.
97328	= 0x17c30 libjimage has this, which rounds up to only 0x18000

libjimage is providing too little data? 
But target vaddr 0x7fa9ff0e4440 is offset into the actual segment 0x00007fa9ff0e4000 by  0x440  (1088 bytes)

0x17c30 + 0x440 = 0x18070 which rounds up to the wanted 0x19000


src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c

399       uintptr_t target_vaddr = lib_php->p_vaddr + lib_base;
400       map_info *existing_map = core_lookup(ph, target_vaddr);

(Existing code expects target_vaddr and existing_map->vaddr to be exactly equal, not to see target_vaddr being anything other than 0x1000 aligned.)

Maybe we:
check if target_vaddr > existing_map->vaddr and add any difference to the library mem size we compare?


429             (ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size))) {

+        uint64_t lib_memsz = lib_php->p_memsz; // check type
+        if (target_vaddr > existing_map->vaddr) {
+            lib_memsz += (target_vaddr - existing_map->vaddr);
+        }
+        lib_memsz = ROUNDUP(lib_memsz, page_size);
+
         if ((existing_map->memsz != page_size) &&
             (existing_map->fd != lib_fd) &&
-            (ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size))) {
+            (ROUNDUP(existing_map->memsz, page_size) != lib_memsz)) {


This is kind of similar to what you had, but maybe the target_vaddr varies and becomes offset even more than pagesize at some point?

Curious if that works for clang builds.  In my builds it doesn't change anything, we don't hit target_vaddr > existing_map->vaddr

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

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3324262154

From mbaesken at openjdk.org  Tue Sep 23 15:11:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 15:11:21 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
Message-ID: <UAYCfIkXY99Mb2oyr4ztXqynDKGpuGFzl9ExQHc0yeA=.e1207a76-7e41-4c48-9c1a-22ec8913f66e@github.com>

On Tue, 23 Sep 2025 08:10:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment regarding LIBSYSLOOKUP and LIBDL

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3324427355

From mbaesken at openjdk.org  Tue Sep 23 15:11:23 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 15:11:23 GMT
Subject: Integrated: 8367913: LIBDL dependency seems to be not needed for some
 jdk libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <Jw7Km9oN3MbAHvBlnNAThYtpWNqnSPmP23fhzFYfEoU=.081728e2-da25-49db-9b1f-32071566f79e@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

This pull request has now been integrated.

Changeset: 82bdef16
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82bdef16390deaa6863cdf8ecf26e6e99f6cb0a2
Stats:     7 lines in 3 files changed: 2 ins; 2 del; 3 mod

8367913: LIBDL dependency seems to be not needed for some jdk libs

Reviewed-by: aivanov, ihse, clanger, mdoerr

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

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

From larry.cable at oracle.com  Tue Sep 23 15:31:31 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Tue, 23 Sep 2025 08:31:31 -0700
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <oM68Gs7U2PdAcJJYitPXlYAALeULpk6Rx5U2uZx54yA=.e372d960-07b3-498a-89d3-14bfc655f3c6@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <oM68Gs7U2PdAcJJYitPXlYAALeULpk6Rx5U2uZx54yA=.e372d960-07b3-498a-89d3-14bfc655f3c6@github.com>
Message-ID: <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>



On 9/23/25 2:59 AM, Thomas Stuefe wrote:
> On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:
>
>> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
>> Adding a timestamp to the output of some would add value for those debugging JVM data.
>>
>> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
>>
>> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
>>
>> The exceptions are:
>> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
>> * `VM.system_properties` - already lists timestamp
>> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
>> * `VM.version`
> Piling on...
>
> I think this feature would be useful. I wished for this more often than not.
>
> I think the printing should be done on the server side, not on the client side (be it a `date` before the invocation of jcmd, or jcmd itself printing the date), since the timestamp on the server side may be different than that of the client jcmd.
>
> I would prefer a timestamp in the UL "time" decoration format: Full ISO-8601, including timezone offset. See https://openjdk.org/jeps/158 . That would also keep in line with gc logs etc.
>
> I am not sure we need a specific option to disable or enable this. Who would want to disable this feature?

anyone who is parsing the output of jcmd's programmatically ... since 
this change can potentially break that code
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3323234159


From sroy at openjdk.org  Tue Sep 23 16:37:58 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 23 Sep 2025 16:37:58 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v4]
In-Reply-To: <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
 <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>
Message-ID: <a0GFViX2wTiCHJO7yqqiXW37H2DcBUKi7JNsdbR8Jso=.f5435cea-59bf-4d62-a677-1b83905ec787@github.com>

On Thu, 7 Aug 2025 05:36:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update ProblemList.txt
>
>> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
>> 
> 
> Who? me? Other Reviewers? Strange PR description ;-)

Hi @tstuefe  
I completely understand you?re busy. Kindly provide a review you get a chance.

Please let me know if you need any additional information from my side.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3324778210

From ayang at openjdk.org  Tue Sep 23 16:47:09 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 23 Sep 2025 16:47:09 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <HAi3fRnbLHuMa4TJ0eJ_oZJ7-np6Kjuos1t-hhTz5H8=.58fcc876-0191-4946-a08b-cce2fa82b320@github.com>

On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3258855405

From schernyshev at openjdk.org  Tue Sep 23 17:03:46 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 23 Sep 2025 17:03:46 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v3]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <gjyA1t_guxP2Za_WS3cDjFlRAeDexPyq-eE3487wMWk=.42fcb060-4750-4ac9-ba2b-1822908c4fb2@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

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

  Apply suggestions from code review
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/779a1b35..de855d37

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

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

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

From schernyshev at openjdk.org  Tue Sep 23 17:03:48 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 23 Sep 2025 17:03:48 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v3]
In-Reply-To: <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
 <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
Message-ID: <vZy2FkRX5gOSp0iEgfrm0D_tCNBtCG5onvxh3qWA2NM=.c5d9f48b-5d0b-4a65-a581-b0b5f2118583@github.com>

On Tue, 23 Sep 2025 02:43:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 49:
> 
>> 47:     // the latter can be changed by the user.
>> 48:     // Any changes to this needs to be synchronized with HotSpot.
>> 49:     private static final String tmpdir;
> 
> So we can't cache this any more?

Thanks David for pointing this out. A different instance with a different PID may have a different temp path, so the path should be specific to the instance. Since we don't need the path outside the constructor, I think we don't need to cache it. On the other hand I see that `getTempDirFromPid` is called twice, once for `.java_pid` and another time in `createAttachFile` when `.java_pid` doesn't exist. Would you suggest storing the path in a local variable in the constructor and then concatenating it with attach file name, or would a non-static member variable be more suitable for this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2372940682

From coleenp at openjdk.org  Tue Sep 23 17:33:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 23 Sep 2025 17:33:54 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>

On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

This looks really good with a couple of minor comments.

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 171:

> 169:   nonstatic_field(Array<Klass*>,               _data[0],                               Klass*)                                       \
> 170:                                                                                                                                      \
> 171:   volatile_nonstatic_field(BasicLock,          _monitor,                               ObjectMonitor*)                               \

I don't see any references to this in the JVMCI code either.  I assume the compiler/jvmci tests all passed with this change without any change to jvmci code.  Maybe @mur47x111  can confirm.

src/hotspot/share/runtime/vmStructs.cpp line 685:

> 683:   volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
> 684:   volatile_nonstatic_field(ObjectMonitor,      _next_om,                                      ObjectMonitor*)                        \
> 685:   volatile_nonstatic_field(BasicLock,          _monitor,                                      ObjectMonitor*)                        \

Since nothing now refers to this, you can delete it from vmStructs.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3258983275
PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2373014053
PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2373006396

From acobbs at openjdk.org  Tue Sep 23 18:06:32 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Sep 2025 18:06:32 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <P1UPwF03g50bB2GIDqYTjZFWjuG_VRzZZrXf_mkALzY=.d7a8cff5-c571-441e-b14d-ba90aec7311e@github.com>

On Sat, 10 May 2025 20:20:32 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

Bumping up the reviewer count to ensure someone from the compiler group approves.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325033159

From amenkov at openjdk.org  Tue Sep 23 20:28:59 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Sep 2025 20:28:59 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock information to
 Thread.dump_to_file
Message-ID: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>

The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.

Testing: tier1..4,hs-tier5-svc

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/27457/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365057
  Stats: 69 lines in 6 files changed: 63 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

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

From prappo at openjdk.org  Tue Sep 23 21:04:59 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 23 Sep 2025 21:04:59 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>

On Sat, 10 May 2025 20:20:32 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

Hi Archie. I've just seen this PR. It looks nice.

While I've read the CSR, I haven't read any compiler-dev thread(s). At least not carefully. I also haven't seen the diff.

IIUC, this annotation can be applied to itself: `@SupressWarnings("suppression")`. Has the scope of `@SupressWarnings` always included the annotation itself, or it's something that you had to tweak in this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325540024

From acobbs at openjdk.org  Tue Sep 23 21:23:47 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Sep 2025 21:23:47 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
Message-ID: <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>

On Tue, 23 Sep 2025 21:02:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While I've read the CSR, I haven't read any compiler-dev thread(s). At least not carefully. I also haven't seen the diff.

FWIW there is a discussion thread (starting [here](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html)), but it's been on/off since November 2024.

> IIUC, this annotation can be applied to itself: `@SupressWarnings("suppression")`. Has the scope of `@SupressWarnings` always included the annotation itself, or it's something that you had to tweak in this PR?

Astute question :) In general, it's completely up to the particular warning. The scope can even extend _before_ the annotation; this is the case with `"dangling-doc-comments"` (see #24600). But normally the "scope" of a declaration includes any annotations on that declaration, simply because the start position of the declaration includes them (the annotations are part of the declaration, not a separate prior thing).

Regarding exactly how "it's completely up to the particular warning": Since #26138, the `DiagnosticPosition` class now has a `getLintPosition()` property. This allows the caller to specify any arbitrary source code position at which to define which `@SuppressWarnings` annotations apply to the warning. Search for `withLintPosition()` to see a couple of uses of it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325592697

From prappo at openjdk.org  Tue Sep 23 21:27:56 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 23 Sep 2025 21:27:56 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
Message-ID: <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>

On Tue, 23 Sep 2025 21:20:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > While I've read the CSR, I haven't read any compiler-dev thread(s). At least not carefully. I also haven't seen the diff.
> 
> FWIW there is a discussion thread (starting [here](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html)), but it's been on/off since November 2024.
> 
> > IIUC, this annotation can be applied to itself: `@SupressWarnings("suppression")`. Has the scope of `@SupressWarnings` always included the annotation itself, or it's something that you had to tweak in this PR?
> 
> Astute question :) In general, it's completely up to the particular warning. The scope can even extend _before_ the annotation; this is the case with `"dangling-doc-comments"` (see #24600). But normally the "scope" of a declaration includes any annotations on that declaration, simply because the start position of the declaration includes them (the annotations are part of the declaration, not a separate prior thing).
> 
> Regarding exactly how "it's completely up to the particular warning": Since #26138, the `DiagnosticPosition` class now has a `getLintPosition()` property. This allows the caller to specify any arbitrary source code position at which to define which `@SuppressWarnings` annotations apply to the warning. Search for `withLintPosition()` to see a couple of uses of it.

The reason I ask is that I can probably see how it could be useful to emit a "suppression" warning from this:

    @SuppressWarnings("suppression")
    public class A { }

I'm not suggesting the PR should implement it, I'm just thinking aloud.

I realise that if it were to implement the annotation as non-self-referring, then there would need to be a way to suppress it too, however silly it may sound.

IIRC there's no way to apply a meta annotation on a _call site_. Even if `@SuppressWarnings` was a `@Repeatable` annotation, this would not have the desired effect:

    @SuppressWarnings("suppression")
    @SuppressWarnings("suppression")
    public void foo(String bar) { ...

Another option is to go one scope higher and put an annotation there:

    @SuppressWarnings("suppression")
    public class FooBar { ...
    
        @SuppressWarnings("suppression")
        public void foo(String bar) { ...

The problem is that you may not have a higher scope. Which sounds like a rare, uninteresting corner case.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325606585

From acobbs at openjdk.org  Tue Sep 23 21:52:26 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Sep 2025 21:52:26 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
Message-ID: <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>

On Tue, 23 Sep 2025 21:25:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> The reason I ask is that I can probably see how it could be useful to emit a "suppression" warning from this:

It's a reasonable option to consider. I think the main worry is that it could complicate build situations where the same code was being compiled with `-Werror` under two different compiler versions. Suppose you had code like this:

method m() {
   // warning here
}

that generated a `"foo"` warning in JDK N but not JDK M. So you do this:

@SuppressWarnings("foo")
method m() {
  // warning here
}

OK, now you get a `"suppression"` warning in JDK M but not JDK N. So next you do this:

@SuppressWarnings({ "foo", "suppression" })
method m() {
  // warning here
}

Oops! Now you get a `"suppression"` warning in JDK N.

Then the only way out would be `-Xlint:-suppression`, which means the feature has caused a wild goose chase and is being somewhat self-defeating.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325659614

From dholmes at openjdk.org  Tue Sep 23 21:56:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Sep 2025 21:56:07 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v3]
In-Reply-To: <vZy2FkRX5gOSp0iEgfrm0D_tCNBtCG5onvxh3qWA2NM=.c5d9f48b-5d0b-4a65-a581-b0b5f2118583@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
 <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
 <vZy2FkRX5gOSp0iEgfrm0D_tCNBtCG5onvxh3qWA2NM=.c5d9f48b-5d0b-4a65-a581-b0b5f2118583@github.com>
Message-ID: <doea2Uy4C1_IOG7Pb3_ph9ZqoJcK6VKipksqGb_BY_M=.ea75aec3-3d0c-45fd-9354-a87a2e1bdc33@github.com>

On Tue, 23 Sep 2025 16:57:34 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 49:
>> 
>>> 47:     // the latter can be changed by the user.
>>> 48:     // Any changes to this needs to be synchronized with HotSpot.
>>> 49:     private static final String tmpdir;
>> 
>> So we can't cache this any more?
>
> Thanks David for pointing this out. A different instance with a different PID may have a different temp path, so the path should be specific to the instance. Since we don't need the path outside the constructor, I think we don't need to cache it. On the other hand I see that `getTempDirFromPid` is called twice, once for `.java_pid` and another time in `createAttachFile` when `.java_pid` doesn't exist. Would you suggest storing the path in a local variable in the constructor and then concatenating it with attach file name, or would a non-static member variable be more suitable for this?

I would save it in a local in the constructor and pass it to `createAttachFile` rather than passing the pid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2373540696

From prappo at openjdk.org  Tue Sep 23 22:28:37 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 23 Sep 2025 22:28:37 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
Message-ID: <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>

On Tue, 23 Sep 2025 21:49:49 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Oops! Now you get a `"suppression"` warning in JDK N.

Thanks for this explanation. I can now see what you mean in the _Different Compiler Versions_ section of the CSR. That's some quality reasoning and future-proofing.

I suppose, it would unnecessarily complicate the design if we stipulate that `@SuppressWarnings("suppression")` should only emit a warning if there are no `@SuppressWarning` in any of the _child scopes_. Note, not just ineffective `@SuppressWarning`s, but none at all.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325741752

From dholmes at openjdk.org  Tue Sep 23 22:54:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Sep 2025 22:54:04 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <4qcEZYuk3_U4nvbEh5EBhAtdJvJxjvvUwWiTlgaTaKk=.91630c2c-57c7-47e9-b4d9-55ea80b0a3f3@github.com>

On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

LGTM2

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3259822820

From sspitsyn at openjdk.org  Tue Sep 23 23:20:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Sep 2025 23:20:45 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <Wxt86Eg4f_h4ifrWKnO-LyGJ_sM64nny4spo6CoEnyk=.92cf116c-1c97-46d8-aa64-19d94812f0ba@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
 <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>
 <Wxt86Eg4f_h4ifrWKnO-LyGJ_sM64nny4spo6CoEnyk=.92cf116c-1c97-46d8-aa64-19d94812f0ba@github.com>
Message-ID: <sPxGx_6ytHNNmHQmDIp1yX-DcdQLLErPWZVbNIAzuz0=.54fa652a-a8a5-41e0-9fbb-f946bbb5176f@github.com>

On Mon, 22 Sep 2025 21:14:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1622:
>> 
>>> 1620: 
>>> 1621: static void invalidate_jvmti_stack(JavaThread* thread) {
>>> 1622:   if (JvmtiExport::can_post_frame_pop() || thread->is_interp_only_mode()) {
>> 
>> Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only?
>> It is invalidated once thread switched to interp only.
>
> It seems odd to me that a method called `invalidate_jvmti_stack()` sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check?

> Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only?

This is a right question to ask, thanks. I agree this confusing. The issue is with the pure continuations which are executed not in a context of a virtual thread. Without this check the following test is stably failed:

  test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest

I'm currently kind of puzzled on how to make this check better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2373659467

From sspitsyn at openjdk.org  Tue Sep 23 23:24:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Sep 2025 23:24:20 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <sPxGx_6ytHNNmHQmDIp1yX-DcdQLLErPWZVbNIAzuz0=.54fa652a-a8a5-41e0-9fbb-f946bbb5176f@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
 <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>
 <Wxt86Eg4f_h4ifrWKnO-LyGJ_sM64nny4spo6CoEnyk=.92cf116c-1c97-46d8-aa64-19d94812f0ba@github.com>
 <sPxGx_6ytHNNmHQmDIp1yX-DcdQLLErPWZVbNIAzuz0=.54fa652a-a8a5-41e0-9fbb-f946bbb5176f@github.com>
Message-ID: <ckpPC1zDgwgOZmeX0T0Pga8jZr8nsB_o0fl5WjAMj5A=.ba5643c7-afd1-47a7-a98e-a3df86025bd5@github.com>

On Tue, 23 Sep 2025 23:18:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It seems odd to me that a method called `invalidate_jvmti_stack()` sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check?
>
>> Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only?
> 
> This is a right question to ask, thanks. I agree this confusing. The issue is with the pure continuations which are executed not in a context of a virtual thread. Without this check the following test is stably failed:
> 
>   test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest
> 
> I'm currently kind of puzzled on how to make this check better.

> It seems odd to me that a method called invalidate_jvmti_stack() sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check?

I can rename this function to `cond_ invalidate_jvmti_stack()` if you want. The `interp_only` check is needed for optimization to avoid a performance overhead of current stack depth invalidation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2373663413

From sspitsyn at openjdk.org  Tue Sep 23 23:27:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Sep 2025 23:27:58 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <ckpPC1zDgwgOZmeX0T0Pga8jZr8nsB_o0fl5WjAMj5A=.ba5643c7-afd1-47a7-a98e-a3df86025bd5@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
 <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>
 <Wxt86Eg4f_h4ifrWKnO-LyGJ_sM64nny4spo6CoEnyk=.92cf116c-1c97-46d8-aa64-19d94812f0ba@github.com>
 <sPxGx_6ytHNNmHQmDIp1yX-DcdQLLErPWZVbNIAzuz0=.54fa652a-a8a5-41e0-9fbb-f946bbb5176f@github.com>
 <ckpPC1zDgwgOZmeX0T0Pga8jZr8nsB_o0fl5WjAMj5A=.ba5643c7-afd1-47a7-a98e-a3df86025bd5@github.com>
Message-ID: <LuZ03-ED4ZMDL6nHdQHV9JqRzLnnSi8xvRqMW5InCQQ=.a69417a4-7574-48b6-9916-bfc2fbe368da@github.com>

On Tue, 23 Sep 2025 23:21:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only?
>> 
>> This is a right question to ask, thanks. I agree this confusing. The issue is with the pure continuations which are executed not in a context of a virtual thread. Without this check the following test is stably failed:
>> 
>>   test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest
>> 
>> I'm currently kind of puzzled on how to make this check better.
>
>> It seems odd to me that a method called invalidate_jvmti_stack() sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check?
> 
> I can rename this function to `cond_ invalidate_jvmti_stack()` if you want. The `interp_only` check is needed for optimization to avoid a performance overhead of current stack depth invalidation.

I was thinking a lot on how to get rid of this current stack depth recalculation mechanism used in `interp_only` mode but have not come with a good approach yet. We have a constant trouble from this mechanism needed for debugger optimization purposes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2373667768

From fyang at openjdk.org  Wed Sep 24 02:22:57 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 24 Sep 2025 02:22:57 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <Ys0Er6WBgRmnIHTlvVoTWtmqVPkoXXUGopy981YeuJQ=.a3acc48b-3a9d-4201-a649-92d41a3572ad@github.com>

On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

@fbredber : Thanks for the ping. Tier1 test passes on linux-riscv64 platform.
The RISC-V part of the change seems fine modulo one minor nit.

src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.hpp line 71:

> 69:   // basic_lock: must be x10 & must point to the basic lock, contents destroyed
> 70:   // temp      : temporary register, must not be scratch register t0 or t1
> 71:   void unlock_object(Register swap, Register obj, Register lock, Register temp, Label& slow_case);

You might want to rename the third param `lock` to `basic_lock`.


void unlock_object(Register swap, Register obj, Register basic_lock, Register temp, Label& slow_case);

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3260355920
PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2373865694

From cjplummer at openjdk.org  Wed Sep 24 05:04:14 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Sep 2025 05:04:14 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <LuZ03-ED4ZMDL6nHdQHV9JqRzLnnSi8xvRqMW5InCQQ=.a69417a4-7574-48b6-9916-bfc2fbe368da@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
 <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>
 <Wxt86Eg4f_h4ifrWKnO-LyGJ_sM64nny4spo6CoEnyk=.92cf116c-1c97-46d8-aa64-19d94812f0ba@github.com>
 <sPxGx_6ytHNNmHQmDIp1yX-DcdQLLErPWZVbNIAzuz0=.54fa652a-a8a5-41e0-9fbb-f946bbb5176f@github.com>
 <ckpPC1zDgwgOZmeX0T0Pga8jZr8nsB_o0fl5WjAMj5A=.ba5643c7-afd1-47a7-a98e-a3df86025bd5@github.com>
 <LuZ03-ED4ZMDL6nHdQHV9JqRzLnnSi8xvRqMW5InCQQ=.a69417a4-7574-48b6-9916-bfc2fbe368da@github.com>
Message-ID: <TIFwQIxSOtbGKAQ1kmUnJox3BmxtEqm9-aC9YKzS9Wo=.936a70ef-c748-44a5-996c-83f57bafacde@github.com>

On Tue, 23 Sep 2025 23:25:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> It seems odd to me that a method called invalidate_jvmti_stack() sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check?
>> 
>> I can rename this function to `cond_ invalidate_jvmti_stack()` if you want. The `interp_only` check is needed for optimization to avoid a performance overhead of current stack depth invalidation.
>
> I was thinking a lot on how to get rid of this current stack depth recalculation mechanism used in `interp_only` mode but have not come with a good approach yet. We have a constant trouble from this mechanism needed for debugger optimization purposes.

> The interp_only check is needed for optimization to avoid a performance overhead of current stack depth invalidation.
But if we are not in interp_only mode isn't it already invalidated?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2374345062

From amitkumar at openjdk.org  Wed Sep 24 06:22:16 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 24 Sep 2025 06:22:16 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <Kc6cji4qzxszvKnO9L0TJfAPHiFPYwjkZrINAmv6gdQ=.dfe307aa-e3cc-4be0-99f3-e3828e013fea@github.com>

On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

s390x Part looks good. tier1 tests with fastdebug and release vm seems stable as well.

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

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3261185513

From alanb at openjdk.org  Wed Sep 24 06:33:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Sep 2025 06:33:15 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <nT132_xU8Usd00or8Q3B9G4hJkepXd5C4ZA-jm711rM=.3b098dad-229c-4abb-aac0-e868fc83c2f3@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 208:

> 206:                 Object parkBlocker = snapshot.parkBlocker();
> 207:                 if (parkBlocker != null) {
> 208:                     String suffix = (snapshot.parkBlockerOwner() != null)

This was `if (snapshot.parkBlockerOwner() instanceof Thread owner)` in the original prototype. It avoids the null check and allow L209 to use owner.threadId(). It also is consistent with the other use of pattern matching with instanceof in this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374569271

From dholmes at openjdk.org  Wed Sep 24 06:41:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Sep 2025 06:41:15 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 52:

> 50: 
> 51:     // the owner of the blockerObject when the object is park blocker and is AQS
> 52:     private Thread parkBlockerOwner;

Just wondering whether it makes sense to make the owner field part of the `ThreadBlocker` record?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374595923

From alanb at openjdk.org  Wed Sep 24 06:41:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Sep 2025 06:41:17 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <YhKAzx3Cb7oPMgpybD50CIu2zxCBEm71Fsg4Oo5ID0g=.fffb9b8e-a4bf-4a6a-9e78-c3ce82858ec3@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 695:

> 693:     }
> 694: 
> 695:     /**

In the contains methods, the comment has "contain the given text", it should "containing the given text". (this was spotted when adding the find method).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374587163

From alanb at openjdk.org  Wed Sep 24 07:07:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Sep 2025 07:07:17 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>
Message-ID: <Cpl13QaRHfsYB3Wv2DxTuuf3FZQcGnlkhwuO6MoH0yY=.b5af99ad-b837-4bdd-8720-f777c2382b86@github.com>

On Wed, 24 Sep 2025 06:38:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 52:
> 
>> 50: 
>> 51:     // the owner of the blockerObject when the object is park blocker and is AQS
>> 52:     private Thread parkBlockerOwner;
> 
> Just wondering whether it makes sense to make the owner field part of the `ThreadBlocker` record?

The parkBlocker is a property of the thread. When the parkBlocker is an AbstractOwnableSynchronizer then the owner is a property of that park blocker type. So yes, in modelling terms it would be more accurate. In practical terms it doesn't matter as it's all encapsulated but there is likely more work in this area so it would be better to get it right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374672607

From duke at openjdk.org  Wed Sep 24 09:12:16 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Wed, 24 Sep 2025 09:12:16 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
Message-ID: <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>

On Tue, 23 Sep 2025 15:33:22 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

> anyone who is parsing the output of jcmd's programmatically ... since this change can potentially break that code

@tstuefe Do you think we would need a CSR for this kind of change?

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3327343529

From stuefe at openjdk.org  Wed Sep 24 09:37:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 Sep 2025 09:37:01 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <i7n8tXj8Wzy5M0y8Bdn5h75eFDFNlTZMgkJBbKSBd8o=.2f43a860-6d33-4cb9-bed4-d1176ac82bf4@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

@larry-cable 
> anyone who is parsing the output of jcmd's programmatically ... since
this change can potentially break that code

yeah, true

@Domest0s 
Hmm, rather than breaking compatibility and requiring a CSR, I now also opt for an option. We are usually not so strict with changing individual commands, but I agree with Larry that changing the format of all commands may be a problem. 

Thinking this a bit further. We may have the same discussion in the future whenever we do fundamental changes to jcmd output. 

As an arbitrary example, let's say someone wants to report the jcmd runtime back at the end of every command (I recently needed that, but abandoned the PR). E.g. a trailing "321ms". Or some other statistics or process specs. Do we want a new diagnostic switch every time? That could get confusing quickly, and these switches need testing.

How about a single "enable jcmd legacy output format" setting. By default on. Behind this setting we guard all future changes that severely change the output of commands. Anyone wanting a stable output would define that setting. 

And how about making this switch a standard *jcmd* option, not a JVM setting? Typically, this decision is made by the analyst running jcmd. That is the person wanting to post-process the output. A JVM switch means the analyst has to restart the JVM with new command-line parameters. That is uncomfortable, and the analyst may even be able to do that (often can't restart client production servers; maybe not even change VM parameters).

Opinions?

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3327445191

From yzheng at openjdk.org  Wed Sep 24 11:16:52 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 24 Sep 2025 11:16:52 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>
Message-ID: <wy38yKqejScqcYbUFCfwmp63GcEe3lABxo_Y4T4jWzc=.5aad2801-9624-4965-889f-dadafd94db73@github.com>

On Tue, 23 Sep 2025 17:30:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a general cleanup after removing `LockingMode` related code.
>> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
>> It includes:
>> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
>> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
>> - Remove "always true" parameter from `MonitorExitStub`.
>> - Re-type/name metadata in `BasicLock`.
>> 
>> Tier1-5 passes okay on supported platforms.
>> 
>> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 171:
> 
>> 169:   nonstatic_field(Array<Klass*>,               _data[0],                               Klass*)                                       \
>> 170:                                                                                                                                      \
>> 171:   volatile_nonstatic_field(BasicLock,          _monitor,                               ObjectMonitor*)                               \
> 
> I don't see any references to this in the JVMCI code either.  I assume the compiler/jvmci tests all passed with this change without any change to jvmci code.  Maybe @mur47x111  can confirm.

Correct, I dont think JVMCI tests will be affected. We only use this field (offset) in the actual monitorenter implementation to write ObjectMonitor cache.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375418781

From fbredberg at openjdk.org  Wed Sep 24 11:47:49 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 24 Sep 2025 11:47:49 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>
Message-ID: <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com>

On Tue, 23 Sep 2025 17:26:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a general cleanup after removing `LockingMode` related code.
>> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
>> It includes:
>> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
>> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
>> - Remove "always true" parameter from `MonitorExitStub`.
>> - Re-type/name metadata in `BasicLock`.
>> 
>> Tier1-5 passes okay on supported platforms.
>> 
>> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.
>
> src/hotspot/share/runtime/vmStructs.cpp line 685:
> 
>> 683:   volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
>> 684:   volatile_nonstatic_field(ObjectMonitor,      _next_om,                                      ObjectMonitor*)                        \
>> 685:   volatile_nonstatic_field(BasicLock,          _monitor,                                      ObjectMonitor*)                        \
> 
> Since nothing now refers to this, you can delete it from vmStructs.

According to @mur47x111, they still need this line for their fast locking implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375512919

From mhaessig at openjdk.org  Wed Sep 24 12:00:20 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 24 Sep 2025 12:00:20 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
Message-ID: <OqHedOUnvbvpWP-wxFSQ-tT8vzpkKfndlbBzmpun-Fk=.94ced09e-0ed3-42ca-ace4-14473a97bede@github.com>

On Tue, 2 Sep 2025 20:52:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert whitespace change
>  - undo debug changes
>  - cleanup

Thank you again for this extensive cleanup. I did another, more thorough, pass and have a few questions and suggestions.

src/hotspot/cpu/arm/arm_32.ad line 436:

> 434:   bool far = (_method == nullptr) ? maybe_far_call(this) : !cache_reachable();
> 435:   return (far ? 3 : 1) * NativeInstruction::instruction_size;
> 436: }

Why do we still need the `instruction_size` offset? Are all static java calls now method handles?

src/hotspot/cpu/arm/frame_arm.cpp line 365:

> 363:       DEBUG_ONLY(verify_deopt_original_pc(sender_nm, _unextended_sp));
> 364:     }
> 365:   }

All of this could be `NOT_PRODUCT` and the method `const` if I did not miss any side effects.

src/hotspot/cpu/arm/frame_arm.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/cpu/arm/register_arm.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/code/debugInfoRec.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/code/nmethod.inline.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/code/pcDesc.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/jvmci/jvmciCodeInstaller.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/opto/matcher.hpp line 1:

> 1: /*

Please update the copyright year.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/PCDesc.java line 1:

> 1: /*

Please update the copyright year.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java line 1:

> 1: /*

Please update the copyright year.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java line 1:

> 1: /*

Please update the copyright year.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java line 1:

> 1: /*

Please update the copyright year.

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

Changes requested by mhaessig (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3262358336
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375411757
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375419504
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375518959
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375519168
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375519398
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375523797
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375524042
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375524330
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375524675
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375525018
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375525797
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375526227
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375527000

From fbredberg at openjdk.org  Wed Sep 24 12:01:41 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 24 Sep 2025 12:01:41 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2]
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <uJwnUQPUypy26GSkID0NczZInxKdMLtSw8SghdetzrE=.2906c023-957c-4a53-8e99-f88faf63df55@github.com>

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

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

  Update after review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27448/files
  - new: https://git.openjdk.org/jdk/pull/27448/files/b5d57851..85457638

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

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

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

From fbredberg at openjdk.org  Wed Sep 24 12:01:43 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 24 Sep 2025 12:01:43 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2]
In-Reply-To: <Ys0Er6WBgRmnIHTlvVoTWtmqVPkoXXUGopy981YeuJQ=.a3acc48b-3a9d-4201-a649-92d41a3572ad@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <Ys0Er6WBgRmnIHTlvVoTWtmqVPkoXXUGopy981YeuJQ=.a3acc48b-3a9d-4201-a649-92d41a3572ad@github.com>
Message-ID: <SlnPEGtvG-8j7q3KO4rXyOAHWjnzWVHu9UnF2IQ9VuU=.187914f4-6deb-4616-a465-3fbd5000ae3a@github.com>

On Wed, 24 Sep 2025 02:09:02 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.hpp line 71:
> 
>> 69:   // basic_lock: must be x10 & must point to the basic lock, contents destroyed
>> 70:   // temp      : temporary register, must not be scratch register t0 or t1
>> 71:   void unlock_object(Register swap, Register obj, Register lock, Register temp, Label& slow_case);
> 
> You might want to rename the third param `lock` to `basic_lock`.
> 
> 
> void unlock_object(Register swap, Register obj, Register basic_lock, Register temp, Label& slow_case);

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375539612

From fbredberg at openjdk.org  Wed Sep 24 12:01:46 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 24 Sep 2025 12:01:46 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2]
In-Reply-To: <wy38yKqejScqcYbUFCfwmp63GcEe3lABxo_Y4T4jWzc=.5aad2801-9624-4965-889f-dadafd94db73@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>
 <wy38yKqejScqcYbUFCfwmp63GcEe3lABxo_Y4T4jWzc=.5aad2801-9624-4965-889f-dadafd94db73@github.com>
Message-ID: <8fpIz-2CpbqESb-a1kb_o8io13ZPzLgyWF1acLUn-A0=.b4a88a33-c938-40c9-aab2-cae6a28b0a45@github.com>

On Wed, 24 Sep 2025 11:13:42 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 171:
>> 
>>> 169:   nonstatic_field(Array<Klass*>,               _data[0],                               Klass*)                                       \
>>> 170:                                                                                                                                      \
>>> 171:   volatile_nonstatic_field(BasicLock,          _monitor,                               ObjectMonitor*)                               \
>> 
>> I don't see any references to this in the JVMCI code either.  I assume the compiler/jvmci tests all passed with this change without any change to jvmci code.  Maybe @mur47x111  can confirm.
>
> Correct, I dont think JVMCI tests will be affected. We only use this field (offset) in the actual monitorenter implementation to write ObjectMonitor cache.
> edit: Sorry I missed the `delete it from vmStructs` context. We need this line for our fast locking implementation

Removed line 171 from `vmStructs_jvmci.cpp`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375544175

From coleenp at openjdk.org  Wed Sep 24 12:50:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 24 Sep 2025 12:50:50 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2]
In-Reply-To: <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>
 <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com>
Message-ID: <WPNIG6zwal8f08gUQQRigkLgljc_CMp4mgnzFurETlo=.c625f3d1-95f2-409a-b413-45f4bc767627@github.com>

On Wed, 24 Sep 2025 11:44:58 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/vmStructs.cpp line 685:
>> 
>>> 683:   volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
>>> 684:   volatile_nonstatic_field(ObjectMonitor,      _next_om,                                      ObjectMonitor*)                        \
>>> 685:   volatile_nonstatic_field(BasicLock,          _monitor,                                      ObjectMonitor*)                        \
>> 
>> Since nothing now refers to this, you can delete it from vmStructs.
>
> According to @mur47x111, they still need this line for their fast locking implementation.

Oh you were supposed to leave the field in vmStructs_jvmci.cpp and remove it from this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375681060

From fbredberg at openjdk.org  Wed Sep 24 12:58:57 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 24 Sep 2025 12:58:57 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2]
In-Reply-To: <WPNIG6zwal8f08gUQQRigkLgljc_CMp4mgnzFurETlo=.c625f3d1-95f2-409a-b413-45f4bc767627@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>
 <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com>
 <WPNIG6zwal8f08gUQQRigkLgljc_CMp4mgnzFurETlo=.c625f3d1-95f2-409a-b413-45f4bc767627@github.com>
Message-ID: <ztmFNX76ysexQ6v5MS048cIWwMda3Q1V_8N32KPD_qA=.48dc7fce-e795-472c-a2ca-c697b60f562c@github.com>

On Wed, 24 Sep 2025 12:48:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> According to @mur47x111, they still need this line for their fast locking implementation.
>
> Oh you were supposed to leave the field in vmStructs_jvmci.cpp and remove it from this one.

Yea, I got it all mixed up in my head. Will fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375703603

From fbredberg at openjdk.org  Wed Sep 24 13:05:23 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 24 Sep 2025 13:05:23 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3]
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <sAJr64i4mNoI0RYcaLPo_LjxRMx6m6EkEf4hqO5Gvxc=.a38d0bed-e66e-41cd-9008-586a68c3c107@github.com>

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

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

  Fixed a mixup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27448/files
  - new: https://git.openjdk.org/jdk/pull/27448/files/85457638..43f9c0af

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

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

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

From fbredberg at openjdk.org  Wed Sep 24 13:05:24 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 24 Sep 2025 13:05:24 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3]
In-Reply-To: <8fpIz-2CpbqESb-a1kb_o8io13ZPzLgyWF1acLUn-A0=.b4a88a33-c938-40c9-aab2-cae6a28b0a45@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>
 <wy38yKqejScqcYbUFCfwmp63GcEe3lABxo_Y4T4jWzc=.5aad2801-9624-4965-889f-dadafd94db73@github.com>
 <8fpIz-2CpbqESb-a1kb_o8io13ZPzLgyWF1acLUn-A0=.b4a88a33-c938-40c9-aab2-cae6a28b0a45@github.com>
Message-ID: <bLkTQFOzy2THXJhzDzHX-_NQwdUk0pgz7ytSseON8uI=.a7f0e8eb-0174-4b76-b390-3c0694f8a023@github.com>

On Wed, 24 Sep 2025 11:58:43 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Correct, I dont think JVMCI tests will be affected. We only use this field (offset) in the actual monitorenter implementation to write ObjectMonitor cache.
>> edit: Sorry I missed the `delete it from vmStructs` context. We need this line for our fast locking implementation
>
> Removed line 171 from `vmStructs_jvmci.cpp`.

Reinstalled line 171 from vmStructs_jvmci.cpp. Sorry for the mixup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375719236

From fbredberg at openjdk.org  Wed Sep 24 13:05:25 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 24 Sep 2025 13:05:25 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3]
In-Reply-To: <ztmFNX76ysexQ6v5MS048cIWwMda3Q1V_8N32KPD_qA=.48dc7fce-e795-472c-a2ca-c697b60f562c@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <ZGtDrmvcx7-3M8fEnRxyetKn4EGEVqWXDD7ycv0jV70=.9fc89a94-3987-4521-a0d9-ce68cae6e93a@github.com>
 <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com>
 <WPNIG6zwal8f08gUQQRigkLgljc_CMp4mgnzFurETlo=.c625f3d1-95f2-409a-b413-45f4bc767627@github.com>
 <ztmFNX76ysexQ6v5MS048cIWwMda3Q1V_8N32KPD_qA=.48dc7fce-e795-472c-a2ca-c697b60f562c@github.com>
Message-ID: <M_zeElZTHHN7ahuBMrLO6wfVzQBuW7xMb46-JkitN3w=.c38a9a89-bcdd-4a51-afb6-ab6870120318@github.com>

On Wed, 24 Sep 2025 12:55:51 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Oh you were supposed to leave the field in vmStructs_jvmci.cpp and remove it from this one.
>
> Yea, I got it all mixed up in my head. Will fix it.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375717181

From coleenp at openjdk.org  Wed Sep 24 13:07:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 24 Sep 2025 13:07:00 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3]
In-Reply-To: <sAJr64i4mNoI0RYcaLPo_LjxRMx6m6EkEf4hqO5Gvxc=.a38d0bed-e66e-41cd-9008-586a68c3c107@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <sAJr64i4mNoI0RYcaLPo_LjxRMx6m6EkEf4hqO5Gvxc=.a38d0bed-e66e-41cd-9008-586a68c3c107@github.com>
Message-ID: <BbjMt9Eci3ZJqMbPMOmvqjee9WaE775XOmE11TUcHKc=.643fad05-97c1-472e-9989-d04b2f8c3219@github.com>

On Wed, 24 Sep 2025 13:05:23 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is a general cleanup after removing `LockingMode` related code.
>> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
>> It includes:
>> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
>> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
>> - Remove "always true" parameter from `MonitorExitStub`.
>> - Re-type/name metadata in `BasicLock`.
>> 
>> Tier1-5 passes okay on supported platforms.
>> 
>> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a mixup

Looks good!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3262810994

From yzheng at openjdk.org  Wed Sep 24 13:13:53 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 24 Sep 2025 13:13:53 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3]
In-Reply-To: <sAJr64i4mNoI0RYcaLPo_LjxRMx6m6EkEf4hqO5Gvxc=.a38d0bed-e66e-41cd-9008-586a68c3c107@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <sAJr64i4mNoI0RYcaLPo_LjxRMx6m6EkEf4hqO5Gvxc=.a38d0bed-e66e-41cd-9008-586a68c3c107@github.com>
Message-ID: <0-k1XZdfzcUtKM2YhXUXW7ySBnZUxyU4DZ-kUpzWSPM=.0cf78c01-e8db-4f55-94b1-a499b5b2fc85@github.com>

On Wed, 24 Sep 2025 13:05:23 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is a general cleanup after removing `LockingMode` related code.
>> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
>> It includes:
>> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
>> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
>> - Remove "always true" parameter from `MonitorExitStub`.
>> - Re-type/name metadata in `BasicLock`.
>> 
>> Tier1-5 passes okay on supported platforms.
>> 
>> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a mixup

LGTM

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3262839280

From acobbs at openjdk.org  Wed Sep 24 15:02:02 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 Sep 2025 15:02:02 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
 <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
Message-ID: <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>

On Tue, 23 Sep 2025 22:26:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Thanks for this explanation. I can now see what you mean in the _Different Compiler Versions_ section of the CSR. That's some quality reasoning and future-proofing.

Credit goes to @jddarcy for pinpointing those possible traps.

> I suppose, it would unnecessarily complicate the design if we stipulate that `@SuppressWarnings("suppression")` should only emit a warning if there are no `@SuppressWarnings` in any of the _child scopes_. Note, not just ineffective `@SuppressWarnings`s, but none at all.

Here's an analogy that helps me justify the current design, fwiw. Have you ever been to New York or another city and walked by an otherwise completely blank wall that has "POST NO BILLS" signs stuck to it, and then thought about how ironic it is that posting bills is required in order to notify people not to post bills?

Sticking `@SuppressWarnings("suppression")` on a declaration is analogous. We're posting a notification not to do something, even though the notification itself risks doing it. But that's OK and we make a special exception for it.

If we didn't make such exceptions, then when you walked by such a wall you'd see a workman repeatedly posting and unposting the "POST NO BILLS" bills :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3329111827

From larry.cable at oracle.com  Wed Sep 24 15:17:14 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 24 Sep 2025 08:17:14 -0700
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <i7n8tXj8Wzy5M0y8Bdn5h75eFDFNlTZMgkJBbKSBd8o=.2f43a860-6d33-4cb9-bed4-d1176ac82bf4@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <i7n8tXj8Wzy5M0y8Bdn5h75eFDFNlTZMgkJBbKSBd8o=.2f43a860-6d33-4cb9-bed4-d1176ac82bf4@github.com>
Message-ID: <074c99da-4cc8-4a5c-813d-c80eff1bdf90@oracle.com>

see inline...

On 9/24/25 2:37 AM, Thomas Stuefe wrote:
> On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:
>
>> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
>> Adding a timestamp to the output of some would add value for those debugging JVM data.
>>
>> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
>>
>> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
>>
>> The exceptions are:
>> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
>> * `VM.system_properties` - already lists timestamp
>> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
>> * `VM.version`
> @larry-cable
>> anyone who is parsing the output of jcmd's programmatically ... since
> this change can potentially break that code
>
> yeah, true
thanks!
> @Domest0s
> Hmm, rather than breaking compatibility and requiring a CSR, I now also opt for an option. We are usually not so strict with changing individual commands, but I agree with Larry that changing the format of all commands may be a problem.

cheers!
>
> Thinking this a bit further. We may have the same discussion in the future whenever we do fundamental changes to jcmd output.

agreed!
>
> As an arbitrary example, let's say someone wants to report the jcmd runtime back at the end of every command (I recently needed that, but abandoned the PR). E.g. a trailing "321ms". Or some other statistics or process specs. Do we want a new diagnostic switch every time? That could get confusing quickly, and these switches need testing.
agreed
>
> How about a single "enable jcmd legacy output format" setting. By default on. Behind this setting we guard all future changes that severely change the output of commands. Anyone wanting a stable output would define that setting.
agreed
>
> And how about making this switch a standard *jcmd* option, not a JVM setting? Typically, this decision is made by the analyst running jcmd. That is the person wanting to post-process the output. A JVM switch means the analyst has to restart the JVM with new command-line parameters. That is uncomfortable, and the analyst may even be able to do that (often can't restart client production servers; maybe not even change VM parameters).
>
> Opinions?

makes sense, I have a (much) larger dream for jcmd etc that I want to 
work on:

1) add Unix Domain Socket support to the (sun) enbedded httpserver
2) expose a UDS endpoint for Jcmds'
3)? add http+json as a transport for commands and responses
4) add mechanism for DCmd to render in json

with json as a payload format such additions would be much simpler...(in 
theory at least)
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3327445191


From stuefe at openjdk.org  Wed Sep 24 16:01:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 Sep 2025 16:01:54 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
 <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
Message-ID: <Hyft89RsM69BGk6qn5yce1-onp39CC0jfXm3a9slbHQ=.8750c3b8-1337-42e2-aadc-c4fd86860406@github.com>

On Wed, 24 Sep 2025 09:09:22 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> see inline\.\.\.
>> 
>> On 9\/24\/25 2\:37 AM\, Thomas Stuefe wrote\:
>>> On Thu\, 18 Sep 2025 14\:57\:44 GMT\, Ivan Bereziuk \<duke at openjdk\.org> wrote\:
>>>
>>>> \`jcmd\` provides great diagnostics but many commands lack a timestamp in their output\.
>>>> Adding a timestamp to the output of some would add value for those debugging JVM data\.
>>>>
>>>> Some diagnostic commands already provide timestamps\. For example \`Thread\.print\` already prints one of \"yyyy\-MM\-dd HH\:mm\:ss\" format\.
>>>>
>>>> Adding timestamps to all diagnostic \`jcmd\` commands with a non\-throw\-away STDOUT\.
>>>>
>>>> The exceptions are\:
>>>> \* \`VM\.uptime\` \- command run with \`\-date\` argument will also print a timestamp\;
>>>> \* \`VM\.system\_properties\` \- already lists timestamp
>>>> \* \`Thread\.dump\_to\_file\` \- the content dumped to file already has a timestamp\;
>>>> \* \`VM\.version\`
>>> \@<!-- -->larry\-cable
>>>> anyone who is parsing the output of jcmd\'s programmatically \.\.\. since
>>> this change can potentially break that code
>>>
>>> yeah\, true
>> 
>> thanks\!
>>> \@<!-- -->Domest0s
>>> Hmm\, rather than breaking compatibility and requiring a CSR\, I now also opt for an option\. We are usually not so strict with changing individual commands\, but I agree with Larry that changing the format of all commands may be a problem\.
>> 
>> cheers\!
>>>
>>> Thinking this a bit further\. We may have the same discussion in the future whenever we do fundamental changes to jcmd output\.
>> 
>> agreed\!
>>>
>>> As an arbitrary example\, let\'s say someone wants to report the jcmd runtime back at the end of every command \(I recently needed that\, but abandoned the PR\)\. E\.g\. a trailing \"321ms\"\. Or some other statistics or process specs\. Do we want a new diagnostic switch every time\? That could get confusing quickly\, and these switches need testing\.
>> 
>> agreed
>>>
>>> How about a single \"enable jcmd legacy output format\" setting\. By default on\. Behind this setting we guard all future changes that severely change the output of commands\. Anyone wanting a stable output would define that setting\.
>> 
>> agreed
>>>
>>> And how about making this switch a standard \*jcmd\* option\, not a JVM setting\? Typically\, this decision is made by the analyst running jcmd\. That is the person wanting to post\-process the output\. A JVM switch means the analyst has to restart the JVM with new command\-line parameters\. That is uncomfortable\, and the analyst may even be able to do that \(often ca...
>
>> anyone who is parsing the output of jcmd's programmatically ... since this change can potentially break that code
> 
> @tstuefe Do you think we would need a CSR for this kind of change?

@Domest0s Let's see if everyone agrees on this.

My proposal would entail
- adding a new standard option to jcmd
- somehow funneling that option to the JVM
- the option should be optional, so that:
  - old jcmd still works with new JVMs (and produces legacy jcmd output)
  - new jcmd still works with old JVMs (and produces legacy jcmd output)

How complex would this be? There are two approaches to this. You can either create a new attach listener protocol (we already have ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or, you can expand the jcmd parsing (see `jcmd(AttachOperation* op, attachStream* out)` in attachListener.cpp).

Not sure whether this would be complex. I understand if this is expanding the scope of your PR too much, in which case I think you should add a new JVM command line option that preserves legacy jcmd output format.

I think you need a CSR in both cases. Not exactly because compatibility would be broken (the jcmd output should stay the same unless this option is explicitly enabled), but because it makes sense to think a bit about the format of this new jcmd option or this new command line flag, and to make the new command line flag product.

Just my 5 cents, let's see what others think first

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3329641686

From stuefe at openjdk.org  Wed Sep 24 16:01:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 Sep 2025 16:01:54 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <074c99da-4cc8-4a5c-813d-c80eff1bdf90@oracle.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <074c99da-4cc8-4a5c-813d-c80eff1bdf90@oracle.com>
Message-ID: <m_KKFdN6syUqPtWPq1x-gzlWDE-GK2kFsKQS1joRYKA=.aa25d740-fb6d-4119-ba2e-983c1f78b71d@github.com>

On Wed, 24 Sep 2025 15:19:18 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

> makes sense, I have a (much) larger dream for jcmd etc that I want to work on:
> 
> 1) add Unix Domain Socket support to the (sun) enbedded httpserver 2) expose a UDS endpoint for Jcmds' 3)? add http+json as a transport for commands and responses 4) add mechanism for DCmd to render in json
> 
> with json as a payload format such additions would be much simpler...(in theory at least)

That sounds interesting, and useful.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3329646138

From prappo at openjdk.org  Wed Sep 24 16:36:32 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 24 Sep 2025 16:36:32 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
 <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
 <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>
Message-ID: <sgelyMB-_LFjIC_qJliK7KkQJHppSN4xmI31lVD325Q=.900df29e-7114-4fa1-b879-6a06225d1f01@github.com>

On Wed, 24 Sep 2025 14:58:38 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > Thanks for this explanation. I can now see what you mean in the _Different Compiler Versions_ section of the CSR. That's some quality reasoning and future-proofing.
> 
> Credit goes to @jddarcy for pinpointing those possible traps.
> 
> > I suppose, it would unnecessarily complicate the design if we stipulate that `@SuppressWarnings("suppression")` should only emit a warning if there are no `@SuppressWarnings` in any of the _child scopes_. Note, not just ineffective `@SuppressWarnings`s, but none at all.
> 
> Here's an analogy that helps me justify the current design, fwiw. Have you ever been to New York or another city and walked by an otherwise completely blank wall that has "POST NO BILLS" signs stuck to it, and then thought about how ironic it is that posting bills is required in order to notify people not to post bills?
> 
> Sticking `@SuppressWarnings("suppression")` on a declaration is analogous. We're posting a notification not to do something, even though the notification itself risks doing it. But that's OK and we make a special exception for it.
> 
> If we didn't make such exceptions, then when you walked by such a wall you'd see a workman repeatedly posting and unposting the "POST NO BILLS" bills :)

That analogy is amusing, but it either barely applies here, or I'm too tired to see how it does.

In my most recent message, I mused about this: _what if `@SuppressWarnings("suppression")` were to emit a warning only if there's no `@SuppressWarnings` of any kind anywhere under it?_ This behaviour is minimally stricter than that of this PR, and is compatible with the M-N-compiler use case.

Basically, if `@SuppressWarnings("suppression")` was accidentally left with no suppressions under it, the compiler would warn you, so you could remove it. Because what's the reason for `@SuppressWarnings("suppression")` whose scope contains no suppressions?

Just to clarify, here's an example of what I mean:

    @SuppressWarnings("suppression")
    public void m() {
        /* a method that contains no @SuppressWarnings
           annotations whatsoever */
    }

Here's an example of what I **don't** mean:

    @SuppressWarnings("suppression")
    public void m() {
        /* a method that only contains @SuppressWarnings
           annotations that are ineffective. That is,
           annotations, that if removed, would __not__
           break compilation with -Werror */
    }

The idea here is to minimise the chance of `@SuppressWarnings("suppression")` becoming part of the furniture and hiding unneeded future suppressions. But maybe changing the behaviour as described above would introduce more complexity and future issues than it would catch potential bugs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3329793388

From acobbs at openjdk.org  Wed Sep 24 16:48:58 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 Sep 2025 16:48:58 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <sgelyMB-_LFjIC_qJliK7KkQJHppSN4xmI31lVD325Q=.900df29e-7114-4fa1-b879-6a06225d1f01@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
 <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
 <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>
 <sgelyMB-_LFjIC_qJliK7KkQJHppSN4xmI31lVD325Q=.900df29e-7114-4fa1-b879-6a06225d1f01@github.com>
Message-ID: <_QblLaoRLKcV6Mf8E3WFd-zpuxn3OKOUHfW0Gez7_0I=.d69c5927-075c-4008-8f62-f447816925f6@github.com>

On Wed, 24 Sep 2025 16:33:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Basically, if `@SuppressWarnings("suppression")` was accidentally left with no suppressions under it, the compiler would warn you, so you could remove it. Because what's the reason for `@SuppressWarnings("suppression")` whose scope contains no suppressions?

Sorry I didn't address this question before - but yes, this is a reasonable ida. It would basically be adding an exception to the exception. So, a bit of additional complexity but for a worthwhile cause. To stretch the analogy, it would be like making the observation: "If the area of the wall is zero, then you never need to post a "POST NO BILLS" bill on it".

I can think of one possible wrinkle though: warnings can actually be suppressed in the source code in two ways, by `@SuppressWarnings` and by `@Deprecated`  (see `Lint.suppressionsFrom(Symbol)`). So you'd also have to look for `@Deprecated`; but this also brings up the unsettling possibility that in the future, some new annotation might have a similar side-effect, and then we'd be in trouble again. So there is an aspect of this idea that requires us to make certain predictions about the future, which of course is dangerous. I think it's safer to "just say no".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3329828755

From amenkov at openjdk.org  Wed Sep 24 19:52:22 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 19:52:22 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <Hyft89RsM69BGk6qn5yce1-onp39CC0jfXm3a9slbHQ=.8750c3b8-1337-42e2-aadc-c4fd86860406@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
 <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
 <Hyft89RsM69BGk6qn5yce1-onp39CC0jfXm3a9slbHQ=.8750c3b8-1337-42e2-aadc-c4fd86860406@github.com>
Message-ID: <dtVog4jA3KB_1c4aGc9RjCeNz9J8JTeyQZWvcrg1mfw=.927816fe-0d84-4b11-a594-4fa701a7eda6@github.com>

On Wed, 24 Sep 2025 15:58:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> My proposal would entail
>     * adding a new standard option to jcmd
>     * somehow funneling that option to the JVM
>     * the option should be optional, so that:
>       * old jcmd still works with new JVMs (and produces legacy jcmd output)
>       * new jcmd still works with old JVMs (and produces legacy jcmd output)
> How complex would this be? There are two approaches to this. You can either create a new attach listener protocol (we already have ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or, you can expand the jcmd parsing (see `jcmd(AttachOperation* op, attachStream* out)` in attachListener.cpp).

ATTACH_API_V2 supports "options".
Client (jcmd) detects options supported by the target VM ("getversion options" command) and can set option values in attach command request.
Currently the only supported option is "streaming" (it allows turn off streaming output).
The option is needed only for tests and needs to work for all attach tools (jcmd, jstack, etc.), so it can be set by specifying java property launching attach tool (like `jcmd -J-Djdk.attach.allowStreamingOutput=false PID command`)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3330432466

From amenkov at openjdk.org  Wed Sep 24 19:59:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 19:59:55 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/b0425b68..5a2a8dc7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=00-01

  Stats: 19 lines in 3 files changed: 5 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

PR: https://git.openjdk.org/jdk/pull/27457

From amenkov at openjdk.org  Wed Sep 24 20:04:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 20:04:32 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <nT132_xU8Usd00or8Q3B9G4hJkepXd5C4ZA-jm711rM=.3b098dad-229c-4abb-aac0-e868fc83c2f3@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <nT132_xU8Usd00or8Q3B9G4hJkepXd5C4ZA-jm711rM=.3b098dad-229c-4abb-aac0-e868fc83c2f3@github.com>
Message-ID: <avSCzUEBJ8P33fqLCvkZ2xhW_Nh3f7DmOjA4eeBvK3s=.de4371a3-0bcc-473b-8a47-7e22e7137967@github.com>

On Wed, 24 Sep 2025 06:30:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 208:
> 
>> 206:                 Object parkBlocker = snapshot.parkBlocker();
>> 207:                 if (parkBlocker != null) {
>> 208:                     String suffix = (snapshot.parkBlockerOwner() != null)
> 
> This was `String suffix = (snapshot.parkBlockerOwner() instanceof Thread owner)` in the original prototype. It avoids the null check and allows L209 to use owner.threadId(). I think I'd prefer it here as it makes it consistent with the other uses of pattern matching with instanceof in this code.

Fixed (and for json version too)

> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 695:
> 
>> 693:     }
>> 694: 
>> 695:     /**
> 
> In the contains methods, the comment has "contain the given text", it should "containing the given text". (this was spotted when adding the find method).

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2376925109
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2376926531

From amenkov at openjdk.org  Wed Sep 24 20:04:34 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 20:04:34 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <Cpl13QaRHfsYB3Wv2DxTuuf3FZQcGnlkhwuO6MoH0yY=.b5af99ad-b837-4bdd-8720-f777c2382b86@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>
 <Cpl13QaRHfsYB3Wv2DxTuuf3FZQcGnlkhwuO6MoH0yY=.b5af99ad-b837-4bdd-8720-f777c2382b86@github.com>
Message-ID: <D8IghIMuy52RLYS8IWTSljAXxKR5rqvIYtM8RBuMv1c=.3bd5aef4-4528-4946-b080-fdf8fc245913@github.com>

On Wed, 24 Sep 2025 07:04:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 52:
>> 
>>> 50: 
>>> 51:     // the owner of the blockerObject when the object is park blocker and is AQS
>>> 52:     private Thread parkBlockerOwner;
>> 
>> Just wondering whether it makes sense to make the owner field part of the `ThreadBlocker` record?
>
> The parkBlocker is a property of the thread. When the parkBlocker is an AbstractOwnableSynchronizer then the owner is a property of that park blocker type. So yes, in modelling terms it would be more accurate. In practical terms it doesn't matter as it's all encapsulated but there is likely more work in this area so it would be better to get it right.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2376925797

From cjplummer at openjdk.org  Wed Sep 24 21:23:32 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Sep 2025 21:23:32 GMT
Subject: RFR: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing
In-Reply-To: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
References: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
Message-ID: <rFWfg7qan6RyQJjkXBTy5QdX-dsrC_ZBOauEYCaSjA8=.a069317c-1d1e-4ca2-9bf0-695847e0010b@github.com>

On Thu, 18 Sep 2025 18:01:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed an issue with a race with two events coming in close to the same time, the first of which does not suspend any debuggee threads. More details in the first comment.
> 
> Tested by running all vmTestbase/nsk/jdi tests 25x times on all platforms both with and w/o virtual threads. Also ran all tier5 svc tests.

Ping!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27370#issuecomment-3330757271

From dlong at openjdk.org  Wed Sep 24 21:25:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 24 Sep 2025 21:25:08 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v4]
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <Frgv6LhsUQjyL5QreJ9prA2DZt8Pjp-h7jXIC0mWEGI=.08186eec-8de0-4b88-82d9-8045dfe07f3a@github.com>

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

Dean Long has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8366461-mh-invoke
 - revert whitespace change
 - undo debug changes
 - cleanup
 - arm32 build
 - Merge branch 'openjdk:master' into 8366461-mh-invoke
 - first pass

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27059/files
  - new: https://git.openjdk.org/jdk/pull/27059/files/eac482a5..a4f2383c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=02-03

  Stats: 179654 lines in 2239 files changed: 141573 ins; 24044 del; 14037 mod
  Patch: https://git.openjdk.org/jdk/pull/27059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059

PR: https://git.openjdk.org/jdk/pull/27059

From dlong at openjdk.org  Wed Sep 24 21:36:30 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 24 Sep 2025 21:36:30 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v5]
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <WKzXDMQOhpumZ832GTJp1fuLhIde30qYYETpmbXGTHQ=.c5d542ca-2e3a-4801-97b6-4f190882db46@github.com>

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  copyright year update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27059/files
  - new: https://git.openjdk.org/jdk/pull/27059/files/a4f2383c..81d56860

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=03-04

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059

PR: https://git.openjdk.org/jdk/pull/27059

From dlong at openjdk.org  Wed Sep 24 21:40:44 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 24 Sep 2025 21:40:44 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <OqHedOUnvbvpWP-wxFSQ-tT8vzpkKfndlbBzmpun-Fk=.94ced09e-0ed3-42ca-ace4-14473a97bede@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <OqHedOUnvbvpWP-wxFSQ-tT8vzpkKfndlbBzmpun-Fk=.94ced09e-0ed3-42ca-ace4-14473a97bede@github.com>
Message-ID: <HbsDQwvXy2dcsJWNZYEWy-auEcQY6_XbsCLjBV2o0Mo=.468dbb3f-533c-4cbc-8b48-9cabd003e35c@github.com>

On Wed, 24 Sep 2025 11:10:22 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - revert whitespace change
>>  - undo debug changes
>>  - cleanup
>
> src/hotspot/cpu/arm/arm_32.ad line 436:
> 
>> 434:   bool far = (_method == nullptr) ? maybe_far_call(this) : !cache_reachable();
>> 435:   return (far ? 3 : 1) * NativeInstruction::instruction_size;
>> 436: }
> 
> Why do we still need the `instruction_size` offset? Are all static java calls now method handles?

The offset is in bytes, so we still need to convert from instruction count to bytes with instruction_size.  This change adjusts for the fact that method handle calls have 1 fewer instruction on arm32 now, because preserve_SP was removed.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java line 1:
> 
>> 1: /*
> 
> Please update the copyright year.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2377135523
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2377136479

From sspitsyn at openjdk.org  Wed Sep 24 21:41:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Sep 2025 21:41:43 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <TIFwQIxSOtbGKAQ1kmUnJox3BmxtEqm9-aC9YKzS9Wo=.936a70ef-c748-44a5-996c-83f57bafacde@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
 <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>
 <Wxt86Eg4f_h4ifrWKnO-LyGJ_sM64nny4spo6CoEnyk=.92cf116c-1c97-46d8-aa64-19d94812f0ba@github.com>
 <sPxGx_6ytHNNmHQmDIp1yX-DcdQLLErPWZVbNIAzuz0=.54fa652a-a8a5-41e0-9fbb-f946bbb5176f@github.com>
 <ckpPC1zDgwgOZmeX0T0Pga8jZr8nsB_o0fl5WjAMj5A=.ba5643c7-afd1-47a7-a98e-a3df86025bd5@github.com>
 <LuZ03-ED4ZMDL6nHdQHV9JqRzLnnSi8xvRqMW5InCQQ=.a69417a4-7574-48b6-9916-bfc2fbe368da@github.com>
 <TIFwQIxSOtbGKAQ1kmUnJox3BmxtEqm9-aC9YKzS9Wo=.936a70ef-c748-44a5-996c-83f57bafacde@github.com>
Message-ID: <ZdiCbSW1RgQAnydDLGxmJ5jBmM5djtbFPZDSu3pl4Hw=.0f124e41-7884-4846-bb10-fd463a9ad469@github.com>

On Wed, 24 Sep 2025 05:02:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> But if we are not in interp_only mode isn't it already invalidated?

It does not need to be invalidated if not in `interp_only` mode.
The issue I see is with the test `test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest` only which is for plain Continuations. Otherwise, the `invalidate_jvmti_stack()` would not be needed. It plays as a workaround to make this test to pass. It seems there is a bug related to plain Continuation lurking somewhere.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2377137978

From dlong at openjdk.org  Wed Sep 24 21:47:29 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 24 Sep 2025 21:47:29 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v6]
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <1ChaRPjjHEx-yM_RJR8JDfbq3v8mhNkkM4WomJstN_o=.ac7eeeed-250e-4511-bdeb-ae720aa5cc20@github.com>

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  copyright year update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27059/files
  - new: https://git.openjdk.org/jdk/pull/27059/files/81d56860..10668bd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059

PR: https://git.openjdk.org/jdk/pull/27059

From cjplummer at openjdk.org  Wed Sep 24 22:09:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Sep 2025 22:09:31 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <ZdiCbSW1RgQAnydDLGxmJ5jBmM5djtbFPZDSu3pl4Hw=.0f124e41-7884-4846-bb10-fd463a9ad469@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
 <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>
 <Wxt86Eg4f_h4ifrWKnO-LyGJ_sM64nny4spo6CoEnyk=.92cf116c-1c97-46d8-aa64-19d94812f0ba@github.com>
 <sPxGx_6ytHNNmHQmDIp1yX-DcdQLLErPWZVbNIAzuz0=.54fa652a-a8a5-41e0-9fbb-f946bbb5176f@github.com>
 <ckpPC1zDgwgOZmeX0T0Pga8jZr8nsB_o0fl5WjAMj5A=.ba5643c7-afd1-47a7-a98e-a3df86025bd5@github.com>
 <LuZ03-ED4ZMDL6nHdQHV9JqRzLnnSi8xvRqMW5InCQQ=.a69417a4-7574-48b6-9916-bfc2fbe368da@github.com>
 <TIFwQIxSOtbGKAQ1kmUnJox3BmxtEqm9-aC9YKzS9Wo=.936a70ef-c748-44a5-996c-83f57bafacde@github.com>
 <ZdiCbSW1RgQAnydDLGxmJ5jBmM5djtbFPZDSu3pl4Hw=.0f124e41-7884-4846-bb10-fd463a9ad469@github.com>
Message-ID: <qWjuzA58LGTKltp0Fszbx0y40e1WAKiupJy2rkImI4c=.10f80fc9-fbf7-4ccc-bebb-ec807684a701@github.com>

On Wed, 24 Sep 2025 21:38:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> The interp_only check is needed for optimization to avoid a performance overhead of current stack depth invalidation.
>> 
>> But if we are not in interp_only mode isn't it already invalidated?
>
>> But if we are not in interp_only mode isn't it already invalidated?
> 
> It does not need to be invalidated if not in `interp_only` mode as it should not be used there or has to be explicitly invalidated exactly where it is needed. The issue I see is only with the test `test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest` which is for plain Continuations. Otherwise, the `invalidate_jvmti_stack()` would not be needed. It plays as a workaround to make this test to pass. It seems there is a bug related to plain Continuations lurking somewhere.

My point is we could just unconditionally invalidate. It would do no harm. It would not be invalidating a curr stack depth that could later be used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2377189171

From dlong at openjdk.org  Wed Sep 24 22:19:03 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 24 Sep 2025 22:19:03 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <OqHedOUnvbvpWP-wxFSQ-tT8vzpkKfndlbBzmpun-Fk=.94ced09e-0ed3-42ca-ace4-14473a97bede@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <OqHedOUnvbvpWP-wxFSQ-tT8vzpkKfndlbBzmpun-Fk=.94ced09e-0ed3-42ca-ace4-14473a97bede@github.com>
Message-ID: <ug-vRNwvLtNwntH63rpqn4ZGu978VXyhTbZ2aBURrAo=.52423675-8cba-4468-8236-1d82001ff6d7@github.com>

On Wed, 24 Sep 2025 11:14:01 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - revert whitespace change
>>  - undo debug changes
>>  - cleanup
>
> src/hotspot/cpu/arm/frame_arm.cpp line 365:
> 
>> 363:       DEBUG_ONLY(verify_deopt_original_pc(sender_nm, _unextended_sp));
>> 364:     }
>> 365:   }
> 
> All of this could be `NOT_PRODUCT` and the method `const` if I did not miss any side effects.

Right, there is no adjustment anymore on any platform.  I think this function and verify_deopt_original_pc only ever existed to support code that is now getting removed.  So I could change the name to verify_unextended_sp() and make it const, but it might make more sense to remove both this function and verify_deopt_original_pc now.  What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2377202692

From duke at openjdk.org  Wed Sep 24 22:27:28 2025
From: duke at openjdk.org (Larry Cable)
Date: Wed, 24 Sep 2025 22:27:28 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <FR9QEZTX6k0npRCC3rYjUjRGOlxFez7pME9IRxzmp7Y=.dbc79198-11f4-45f5-ab78-3f34c0564d04@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

On 9/24/25 12:50 PM, Alex Menkov wrote:
> *alexmenkov* left a comment (openjdk/jdk#27368) 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27368*issuecomment-3330432466__;Iw!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYmYB9_KGw$>
>
>     My proposal would entail
>     * adding a new standard option to jcmd
>     * somehow funneling that option to the JVM
>     * the option should be optional, so that:
>     * old jcmd still works with new JVMs (and produces legacy jcmd output)
>     * new jcmd still works with old JVMs (and produces legacy jcmd output)
>     How complex would this be? There are two approaches to this. You
>     can either create a new attach listener protocol (we already have
>     ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or,
>     you can expand the jcmd parsing (see |jcmd(AttachOperation* op,
>     attachStream* out)| in attachListener.cpp).
>
> ATTACH_API_V2 supports "options".
> Client (jcmd) detects options supported by the target VM ("getversion 
> options" command) and can set option values in attach command request.
> Currently the only supported option is "streaming" (it allows turn off 
> streaming output).
> The option is needed only for tests and needs to work for all attach 
> tools (jcmd, jstack, etc.), so it can be set by specifying java 
> property launching attach tool (like |jcmd 
> -J-Djdk.attach.allowStreamingOutput=false PID command|)
>

sounds like a plan!

> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27368*issuecomment-3330432466__;Iw!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYmYB9_KGw$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SGRSQRLDJZAM3LPRT3ULYW5AVCNFSM6AAAAACG4ANNIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMZQGQZTENBWGY__;!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYk7VM8-7g$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------oR0JTaz5Fop00jaWhAnzYKGf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 9/24/25 12:50 PM, Alex Menkov wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <div style="display: flex; flex-wrap: wrap; white-space: pre-wrap; align-items: center; "><img height="20" width="20" style="border-radius:50%; margin-right: 4px;" decoding="async" src="https://avatars.githubusercontent.com/u/69548902?s=20&amp;v=4" moz-do-not-send="true"><strong>alexmenkov</strong> left a comment <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27368*issuecomment-3330432466__;Iw!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYmYB9_KGw$" moz-do-not-send="true">(openjdk/jdk#27368)</a></div>
      <blockquote>
        <p dir="auto">My proposal would entail<br>
          * adding a new standard option to jcmd<br>
          * somehow funneling that option to the JVM<br>
          * the option should be optional, so that:<br>
          * old jcmd still works with new JVMs (and produces legacy jcmd
          output)<br>
          * new jcmd still works with old JVMs (and produces legacy jcmd
          output)<br>
          How complex would this be? There are two approaches to this.
          You can either create a new attach listener protocol (we
          already have ATTACH_API_V2 vs ATTACH_API_V1, so the precedence
          is there). Or, you can expand the jcmd parsing (see <code class="notranslate">jcmd(AttachOperation* op, attachStream*
            out)</code> in attachListener.cpp).</p>
      </blockquote>
      <p dir="auto">ATTACH_API_V2 supports &quot;options&quot;.<br>
        Client (jcmd) detects options supported by the target VM
        (&quot;getversion options&quot; command) and can set option values in
        attach command request.<br>
        Currently the only supported option is &quot;streaming&quot; (it allows
        turn off streaming output).<br>
        The option is needed only for tests and needs to work for all
        attach tools (jcmd, jstack, etc.), so it can be set by
        specifying java property launching attach tool (like <code class="notranslate">jcmd
          -J-Djdk.attach.allowStreamingOutput=false PID command</code>)</p>
    </blockquote>
    <br>
    sounds like a plan!<br>
    <br>
    <blockquote type="cite" ***@***.***">
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27368*issuecomment-3330432466__;Iw!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYmYB9_KGw$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SGRSQRLDJZAM3LPRT3ULYW5AVCNFSM6AAAAACG4ANNIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMZQGQZTENBWGY__;!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYk7VM8-7g$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67WKNASEIPXUMLRQ5RD3ULYW5A5CNFSM6AAAAACG4ANNIKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTWGQJO5E.gif" height="1" width="1" alt="" moz-do-not-send="true"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/27368/c3330432466</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/27368#issuecomment-3330432466",
"url": "https://github.com/openjdk/jdk/pull/27368#issuecomment-3330432466",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------oR0JTaz5Fop00jaWhAnzYKGf--

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3330902786

From amenkov at openjdk.org  Wed Sep 24 22:30:16 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 22:30:16 GMT
Subject: RFR: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing
In-Reply-To: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
References: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
Message-ID: <iOz4L4p7bW02dLUhz5UIAdYi7-zq7fMPMMsL7sOGx0Y=.f0a756b3-720b-41fa-a6f9-7e5ed160ca53@github.com>

On Thu, 18 Sep 2025 18:01:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed an issue with a race with two events coming in close to the same time, the first of which does not suspend any debuggee threads. More details in the first comment.
> 
> Tested by running all vmTestbase/nsk/jdi tests 25x times on all platforms both with and w/o virtual threads. Also ran all tier5 svc tests.

The fix looks good.

> Note I also removed the synchronize(EventHandler.this) from the listener. EventHandler.run() already does the same synchronize before calling the listener. I did the same in the listener being used for the "breakoint for communication". I checked all other eventReceived() callbacks, and didn't find any others using this synchronization.

I see the same synchronization in the listener for VMDisconnectEvent (starting from line 345 in EventHandler.java)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27370#issuecomment-3330907343

From cjplummer at openjdk.org  Wed Sep 24 23:32:30 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Sep 2025 23:32:30 GMT
Subject: RFR: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing [v2]
In-Reply-To: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
References: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
Message-ID: <zX-c8zkKFhNyOgDEvolme0OApFyIW6HjQEkAqe5TRog=.602a87ab-d449-4d6b-a848-76123f87581c@github.com>

> Fixed an issue with a race with two events coming in close to the same time, the first of which does not suspend any debuggee threads. More details in the first comment.
> 
> Tested by running all vmTestbase/nsk/jdi tests 25x times on all platforms both with and w/o virtual threads. Also ran all tier5 svc tests.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  remove unneeded synchronized

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27370/files
  - new: https://git.openjdk.org/jdk/pull/27370/files/6eac67ab..1849f079

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27370&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27370&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27370/head:pull/27370

PR: https://git.openjdk.org/jdk/pull/27370

From cjplummer at openjdk.org  Wed Sep 24 23:32:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Sep 2025 23:32:31 GMT
Subject: RFR: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing
In-Reply-To: <iOz4L4p7bW02dLUhz5UIAdYi7-zq7fMPMMsL7sOGx0Y=.f0a756b3-720b-41fa-a6f9-7e5ed160ca53@github.com>
References: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
 <iOz4L4p7bW02dLUhz5UIAdYi7-zq7fMPMMsL7sOGx0Y=.f0a756b3-720b-41fa-a6f9-7e5ed160ca53@github.com>
Message-ID: <KM9_QseoyUAL4E0MMG_bZCM71vsF-4fTfx-e-XmgPpA=.ec484435-5683-4059-b910-8a16a860987a@github.com>

On Wed, 24 Sep 2025 22:27:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I see the same synchronization in the listener for VMDisconnectEvent (starting from line 345 in EventHandler.java)

Ok. I've cleaned that one up now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27370#issuecomment-3331009269

From sspitsyn at openjdk.org  Thu Sep 25 00:12:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Sep 2025 00:12:40 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v2]
In-Reply-To: <qWjuzA58LGTKltp0Fszbx0y40e1WAKiupJy2rkImI4c=.10f80fc9-fbf7-4ccc-bebb-ec807684a701@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <IBVy8SqQwTttPfjJDKBPuRWuerEzFAIN9Kx3LavVtVc=.0dc0211d-5600-4aea-b681-6dccbaa4eac6@github.com>
 <nr0fKmYtg-lyyXUfdNcWAlgp-f96VleyJPeW5OWpTSw=.5c4821ea-c187-4ba3-8ea5-e0ff6c049fe1@github.com>
 <Wxt86Eg4f_h4ifrWKnO-LyGJ_sM64nny4spo6CoEnyk=.92cf116c-1c97-46d8-aa64-19d94812f0ba@github.com>
 <sPxGx_6ytHNNmHQmDIp1yX-DcdQLLErPWZVbNIAzuz0=.54fa652a-a8a5-41e0-9fbb-f946bbb5176f@github.com>
 <ckpPC1zDgwgOZmeX0T0Pga8jZr8nsB_o0fl5WjAMj5A=.ba5643c7-afd1-47a7-a98e-a3df86025bd5@github.com>
 <LuZ03-ED4ZMDL6nHdQHV9JqRzLnnSi8xvRqMW5InCQQ=.a69417a4-7574-48b6-9916-bfc2fbe368da@github.com>
 <TIFwQIxSOtbGKAQ1kmUnJox3BmxtEqm9-aC9YKzS9Wo=.936a70ef-c748-44a5-996c-83f57bafacde@github.com>
 <ZdiCbSW1RgQAnydDLGxmJ5jBmM5djtbFPZDSu3pl4Hw=.0f124e41-7884-4846-bb10-fd463a9ad469@github.com>
 <qWjuzA58LGTKltp0Fszbx0y40e1WAKiupJy2rkImI4c=.10f80fc9-fbf7-4ccc-bebb-ec807684a701@github.com>
Message-ID: <WX-fCfvVEJvJAyuSCyzKp7WMvGTKnFW6n7n8pxPL2Ss=.19bfdd4a-1232-45c3-aa12-86c2531539d2@github.com>

On Wed, 24 Sep 2025 22:06:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> But if we are not in interp_only mode isn't it already invalidated?
>> 
>> It does not need to be invalidated if not in `interp_only` mode as it should not be used there or has to be explicitly invalidated exactly where it is needed (the frame pops cleaning code for plain Continuations). The issue I see is only with the test `test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest` which is for plain Continuations. Otherwise, the `invalidate_jvmti_stack()` would not be needed. It plays as a workaround to make this test to pass. It seems there is a bug related to plain Continuations lurking somewhere.
>
> My point is we could just unconditionally invalidate. It would do no harm. It would not be invalidating a curr stack depth that could later be used.

Okay, thanks! I'll make it unconditional. I do not see any performance degradation with that. Also, it will keep the `test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest` test passed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2377332233

From sspitsyn at openjdk.org  Thu Sep 25 00:18:02 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Sep 2025 00:18:02 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v3]
In-Reply-To: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
Message-ID: <quKShG5JIkQmp6SobiXv6_-lh-BkoqJcY3aF8hYb3ko=.21a5225e-6ed6-44f3-899c-906326b615cc@github.com>

> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown.
> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger  the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`.
> 
> Testing:
> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent
> - Mach5 tiers 1-6 are all passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: remove unneeded condition from invalidate_jvmti_stack()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27403/files
  - new: https://git.openjdk.org/jdk/pull/27403/files/4b0478fc..52309bce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27403&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27403&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27403.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27403/head:pull/27403

PR: https://git.openjdk.org/jdk/pull/27403

From lmesnik at openjdk.org  Thu Sep 25 00:24:05 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 25 Sep 2025 00:24:05 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v3]
In-Reply-To: <quKShG5JIkQmp6SobiXv6_-lh-BkoqJcY3aF8hYb3ko=.21a5225e-6ed6-44f3-899c-906326b615cc@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <quKShG5JIkQmp6SobiXv6_-lh-BkoqJcY3aF8hYb3ko=.21a5225e-6ed6-44f3-899c-906326b615cc@github.com>
Message-ID: <Qk5DehMNINmIcH1MH0ENiuWWnHZSO-JS29jj7zQjZHg=.fb2ed6cb-35d9-4f72-b5b3-19fc954e7475@github.com>

On Thu, 25 Sep 2025 00:18:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown.
>> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger  the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`.
>> 
>> Testing:
>> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent
>> - Mach5 tiers 1-6 are all passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove unneeded condition from invalidate_jvmti_stack()

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27403#pullrequestreview-3265088332

From amenkov at openjdk.org  Thu Sep 25 01:36:07 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 01:36:07 GMT
Subject: RFR: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing [v2]
In-Reply-To: <zX-c8zkKFhNyOgDEvolme0OApFyIW6HjQEkAqe5TRog=.602a87ab-d449-4d6b-a848-76123f87581c@github.com>
References: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
 <zX-c8zkKFhNyOgDEvolme0OApFyIW6HjQEkAqe5TRog=.602a87ab-d449-4d6b-a848-76123f87581c@github.com>
Message-ID: <ad7j81G0JU-VROpCKB33n6UhmbgXQDDbsGI88y9PExs=.34b96e85-5882-4f8d-9ea3-c7fe7b40a3dd@github.com>

On Wed, 24 Sep 2025 23:32:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fixed an issue with a race with two events coming in close to the same time, the first of which does not suspend any debuggee threads. More details in the first comment.
>> 
>> Tested by running all vmTestbase/nsk/jdi tests 25x times on all platforms both with and w/o virtual threads. Also ran all tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unneeded synchronized

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27370#pullrequestreview-3265218488

From sspitsyn at openjdk.org  Thu Sep 25 01:42:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Sep 2025 01:42:48 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:

> 686: 
> 687:     /**
> 688:      * Returns true if lines of a plain text thread dump containing the given text.

Nit: Should it be: "...if lines of a plain text thread dump **is** containing" ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377441081

From dholmes at openjdk.org  Thu Sep 25 02:06:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Sep 2025 02:06:29 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Looks good.

src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 83:

> 81:                           "owner": {
> 82:                             "type": "string",
> 83:                             "description": "The thread identifier of the owner when the parkBlocker is an AbstractOwnableSynchronizer."

Is it possible for there to not be an owner? If so what does this report?

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 696:

> 694: 
> 695:     /**
> 696:      * Finds the line of plain text thread dump containing the given text.

Suggestion:

     * Finds the line of a plain text thread dump containing the given text.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3265266068
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377469785
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377472831

From dholmes at openjdk.org  Thu Sep 25 02:06:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Sep 2025 02:06:31 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
Message-ID: <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>

On Thu, 25 Sep 2025 01:40:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:
> 
>> 686: 
>> 687:     /**
>> 688:      * Returns true if lines of a plain text thread dump containing the given text.
> 
> Nit: Should it be: "...if lines of a plain text thread dump **is** containing" ?

The original "contain" was correct. Alternatively:
> Returns true if lines is a plain text thread dump containing the given text.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377472427

From dholmes at openjdk.org  Thu Sep 25 02:09:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Sep 2025 02:09:35 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3]
In-Reply-To: <sAJr64i4mNoI0RYcaLPo_LjxRMx6m6EkEf4hqO5Gvxc=.a38d0bed-e66e-41cd-9008-586a68c3c107@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <sAJr64i4mNoI0RYcaLPo_LjxRMx6m6EkEf4hqO5Gvxc=.a38d0bed-e66e-41cd-9008-586a68c3c107@github.com>
Message-ID: <ydkGcNMi-8jK_21DkYQN9EysFHia4_aHYwXu2uqky_I=.4bbdb470-69eb-4a65-9514-adba5f2fc601@github.com>

On Wed, 24 Sep 2025 13:05:23 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is a general cleanup after removing `LockingMode` related code.
>> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
>> It includes:
>> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
>> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
>> - Remove "always true" parameter from `MonitorExitStub`.
>> - Re-type/name metadata in `BasicLock`.
>> 
>> Tier1-5 passes okay on supported platforms.
>> 
>> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a mixup

Still good.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3265275100

From cjplummer at openjdk.org  Thu Sep 25 04:19:36 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 25 Sep 2025 04:19:36 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v3]
In-Reply-To: <quKShG5JIkQmp6SobiXv6_-lh-BkoqJcY3aF8hYb3ko=.21a5225e-6ed6-44f3-899c-906326b615cc@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <quKShG5JIkQmp6SobiXv6_-lh-BkoqJcY3aF8hYb3ko=.21a5225e-6ed6-44f3-899c-906326b615cc@github.com>
Message-ID: <RP24BQ1Dh4a3MkaijrCVNWhKKl0u7vEkTpvnTqNxRdM=.7c5f74fb-d641-4158-bdeb-c215166b9c82@github.com>

On Thu, 25 Sep 2025 00:18:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown.
>> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger  the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`.
>> 
>> Testing:
>> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent
>> - Mach5 tiers 1-6 are all passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove unneeded condition from invalidate_jvmti_stack()

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27403#pullrequestreview-3265601862

From sspitsyn at openjdk.org  Thu Sep 25 05:44:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Sep 2025 05:44:35 GMT
Subject: RFR: 8368159: Significant performance overhead when started with
 jdwp agent and unattached debugger [v3]
In-Reply-To: <quKShG5JIkQmp6SobiXv6_-lh-BkoqJcY3aF8hYb3ko=.21a5225e-6ed6-44f3-899c-906326b615cc@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
 <quKShG5JIkQmp6SobiXv6_-lh-BkoqJcY3aF8hYb3ko=.21a5225e-6ed6-44f3-899c-906326b615cc@github.com>
Message-ID: <S7L1SnHeUyNSCz4mRfyyE7y0qEQ-aR4cwgrSLkmkCJs=.b081c0f9-13fb-4cb5-8ba3-293f7912da38@github.com>

On Thu, 25 Sep 2025 00:18:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown.
>> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger  the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`.
>> 
>> Testing:
>> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent
>> - Mach5 tiers 1-6 are all passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove unneeded condition from invalidate_jvmti_stack()

Chris and Leonid, thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27403#issuecomment-3332225678

From sspitsyn at openjdk.org  Thu Sep 25 05:44:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Sep 2025 05:44:36 GMT
Subject: Integrated: 8368159: Significant performance overhead when started
 with jdwp agent and unattached debugger
In-Reply-To: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
References: <bKrV58ZO_KRtyibGU9BAlqAZEL0wNb41g_TCevn122A=.06dde8bb-3748-4575-884f-6cc3e71efdd3@github.com>
Message-ID: <r1CWtOM3myHMdBIAzsRO5Cu2AEAGC6fEoZRc2BjPniA=.ecf108a9-849c-4ade-8ec1-2cfe0a9a6f17@github.com>

On Sat, 20 Sep 2025 04:40:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown.
> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger  the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`.
> 
> Testing:
> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent
> - Mach5 tiers 1-6 are all passed

This pull request has now been integrated.

Changeset: 17244c69
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17244c699ad20fafe7448678a53266ce6bf017e5
Stats:     24 lines in 3 files changed: 18 ins; 1 del; 5 mod

8368159: Significant performance overhead when started with jdwp agent and unattached debugger

Reviewed-by: lmesnik, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/27403

From stuefe at openjdk.org  Thu Sep 25 06:12:30 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 25 Sep 2025 06:12:30 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v6]
In-Reply-To: <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
Message-ID: <t7sUStz5mQ-yJeIdXkGCECfCdEyBh4PA_Q8FGKhtR8c=.04f5c602-aa8e-4caf-a05b-e43e3a963ab3@github.com>

On Fri, 29 Aug 2025 08:56:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy 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 branch 'openjdk:master' into cpuprocessload
>  - Thread safety,struct and perfInit()
>  - Thread safety,struct and perfInit()
>  - Update ProblemList.txt
>  - Merge branch 'master' into cpuprocessload
>  - Merge branch 'master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - cleanup
>  - system cpu load
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/86d6a2e0...46dcf313

@JoKern65 could you take a look at this and possibly give a review?

@suchismith1993 Sorry, I'm busy and will be gone starting next week for most of October. Maybe Joachim and @MBaesken or @TheRealMDoerr can help. If they approve, I am fine with their reviews.

Cheers, Thomas

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3332322591

From alanb at openjdk.org  Thu Sep 25 06:32:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 06:32:31 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>
Message-ID: <-VWVWqC03kK76gkiGdkn65JRZYsNALKotU0ImMU4axI=.25e58e0a-3a8e-4c6a-9280-4ca00b110879@github.com>

On Thu, 25 Sep 2025 01:59:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 83:
> 
>> 81:                           "owner": {
>> 82:                             "type": "string",
>> 83:                             "description": "The thread identifier of the owner when the parkBlocker is an AbstractOwnableSynchronizer."
> 
> Is it possible for there to not be an owner? If so what does this report?

In the schema, the only require property of a parkBlocker is "object". The "owner" is optional.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377894888

From alanb at openjdk.org  Thu Sep 25 06:36:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 06:36:48 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <cIjt_YSfVx-OGTkQwCrj1Hn9HzGcfRknNXxUP4lyWpA=.61e50aa3-7481-4c30-be69-0bf70df76a46@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 87:

> 85:                           "required": [
> 86:                             "object"
> 87:                           ]

At L122 the null in the items object should be in quotes, as in "null", and the description ending in ".. null if eliminated" needs a period. There were in the first prototype but didn't make it into the PR patch for some reason. (It came up when using the updated JSON schema, wasn't noticed previously).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377903090

From alanb at openjdk.org  Thu Sep 25 06:50:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 06:50:01 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <oxZPKpXQMZm38uh-MplGAT_FK-eQhc1Tjf8fV10KDhs=.b20c0974-b2ed-4a5a-8dd4-513db8f4693e@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 445:

> 443:             assertNotNull(parkBlocker);
> 444:             assertTrue(parkBlocker.contains("java.util.concurrent.locks.ReentrantLock"));
> 445: 

Will you add 8365057 to the `@bug` at the top?

test/lib/jdk/test/lib/threaddump/ThreadDump.java line 300:

> 298: 
> 299:         /**
> 300:          * Returns the owner of the parkBlocker if the parkBlocker is an AQS.

Can you change "AQS" to AbstractOwnableSynchronizer here? It could be changed to AOS too but few will know what it means.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377924570
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377928658

From mhaessig at openjdk.org  Thu Sep 25 06:51:09 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 25 Sep 2025 06:51:09 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <ug-vRNwvLtNwntH63rpqn4ZGu978VXyhTbZ2aBURrAo=.52423675-8cba-4468-8236-1d82001ff6d7@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <OqHedOUnvbvpWP-wxFSQ-tT8vzpkKfndlbBzmpun-Fk=.94ced09e-0ed3-42ca-ace4-14473a97bede@github.com>
 <ug-vRNwvLtNwntH63rpqn4ZGu978VXyhTbZ2aBURrAo=.52423675-8cba-4468-8236-1d82001ff6d7@github.com>
Message-ID: <QlAr_4lTaGeC_tCezdxQnOnwAeIH3qVU9yMUT7Pf9CI=.2f4f3978-d455-4a8b-8616-28b61c160dfc@github.com>

On Wed, 24 Sep 2025 22:16:17 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/cpu/arm/frame_arm.cpp line 365:
>> 
>>> 363:       DEBUG_ONLY(verify_deopt_original_pc(sender_nm, _unextended_sp));
>>> 364:     }
>>> 365:   }
>> 
>> All of this could be `NOT_PRODUCT` and the method `const` if I did not miss any side effects.
>
> Right, there is no adjustment anymore on any platform.  I think this function and verify_deopt_original_pc only ever existed to support code that is now getting removed.  So I could change the name to verify_unextended_sp() and make it const, but it might make more sense to remove both this function and verify_deopt_original_pc now.  What do you think?

I would rather keep this code as a debug only sanity check, but I would refactor it into a single function. Then the question remains what to do with the SA code, that still does nothing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2377932365

From alanb at openjdk.org  Thu Sep 25 07:00:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 07:00:31 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
 <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
Message-ID: <tuTOeqxpBCJd5jDMbYEmMx8dkGs9-qcA73taHWf_0jY=.5ca6438c-c629-482c-90c9-10cce78536ff@github.com>

On Wed, 24 Sep 2025 09:09:22 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> Do you think we would need a CSR for this kind of change?

The output from several commands have changed over many releases/years, the output from Thread.dump in particular. AFAIK, none of these changes has a CSR, there were only CSRs when new commands were added. That said, if there is some evidence that the output is being parsed then there is a compatibility concern so creating a CSR and RN would prudent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3332451741

From alanb at openjdk.org  Thu Sep 25 07:08:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 07:08:03 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <HNCpHfQDIgYoUPZ1MYH5HQh39LJ7t-w-3adgRfBHZzg=.bbb318b1-4c43-460b-a9a5-8a9183105989@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 47:

> 45:     private int blockerTypeOrdinal;
> 46:     private Object blockerObject;
> 47:     // the owner of the blockerObject when the object is park blocker and is AQS

Typo here, AQS != AbstractOwnableSynchronizer

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377970208

From fbredberg at openjdk.org  Thu Sep 25 08:19:21 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 25 Sep 2025 08:19:21 GMT
Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3]
In-Reply-To: <sAJr64i4mNoI0RYcaLPo_LjxRMx6m6EkEf4hqO5Gvxc=.a38d0bed-e66e-41cd-9008-586a68c3c107@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
 <sAJr64i4mNoI0RYcaLPo_LjxRMx6m6EkEf4hqO5Gvxc=.a38d0bed-e66e-41cd-9008-586a68c3c107@github.com>
Message-ID: <1jgUzSlIIf8uo55h2Ai9cPZjmqQ6OyYs61j2TtgfH8w=.09872546-a1c0-44bc-afe8-d5b26fcf3889@github.com>

On Wed, 24 Sep 2025 13:05:23 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is a general cleanup after removing `LockingMode` related code.
>> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
>> It includes:
>> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
>> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
>> - Remove "always true" parameter from `MonitorExitStub`.
>> - Re-type/name metadata in `BasicLock`.
>> 
>> Tier1-5 passes okay on supported platforms.
>> 
>> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a mixup

Thank you all for the reviews. Now let's...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27448#issuecomment-3332749700

From fbredberg at openjdk.org  Thu Sep 25 08:19:22 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 25 Sep 2025 08:19:22 GMT
Subject: Integrated: 8365191: Cleanup after removing LockingMode related code
In-Reply-To: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
References: <Y-PMz0WNESBTp2l9erSmu2BYc6oKdo-HGJqTzcFUHA8=.5bdab243-649f-4378-8967-1585a8eac4cc@github.com>
Message-ID: <wJjy6pMDNQcS8MO8vZrt3SK_FCv7sKf0VqoNRM9nCTY=.ccdc288d-923a-4f79-857b-c7f91eccf92f@github.com>

On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking.
> - Removing or rewriting comments, arguments or functions that are related to displaced headers.
> - Remove "always true" parameter from `MonitorExitStub`.
> - Re-type/name metadata in `BasicLock`.
> 
> Tier1-5 passes okay on supported platforms.
> 
> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu.

This pull request has now been integrated.

Changeset: 847b107d
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/847b107df821e0c1d347383f1858d505137eb724
Stats:     169 lines in 34 files changed: 2 ins; 44 del; 123 mod

8365191: Cleanup after removing LockingMode related code

Reviewed-by: coleenp, dholmes, yzheng, mdoerr, ayang, fyang, amitkumar

-------------

PR: https://git.openjdk.org/jdk/pull/27448

From schernyshev at openjdk.org  Thu Sep 25 08:38:41 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 25 Sep 2025 08:38:41 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v4]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <_7eEGrVgRXbUpI9iMW8So9q4VGbRJcUB5pjND-TblX0=.57aae041-83e6-45eb-b7a7-66052d6d1ba3@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  addressed review comment #2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/de855d37..9ca4aaf0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=02-03

  Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25824.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25824/head:pull/25824

PR: https://git.openjdk.org/jdk/pull/25824

From schernyshev at openjdk.org  Thu Sep 25 08:46:12 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 25 Sep 2025 08:46:12 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v4]
In-Reply-To: <doea2Uy4C1_IOG7Pb3_ph9ZqoJcK6VKipksqGb_BY_M=.ea75aec3-3d0c-45fd-9354-a87a2e1bdc33@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
 <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
 <vZy2FkRX5gOSp0iEgfrm0D_tCNBtCG5onvxh3qWA2NM=.c5d9f48b-5d0b-4a65-a581-b0b5f2118583@github.com>
 <doea2Uy4C1_IOG7Pb3_ph9ZqoJcK6VKipksqGb_BY_M=.ea75aec3-3d0c-45fd-9354-a87a2e1bdc33@github.com>
Message-ID: <77sm3LvHu0reeiXw8rcTbGCitWVHdBIO9fRCMNOJ9Wo=.bf6fa3f9-cb6e-4602-8c4b-33cf098c4e39@github.com>

On Tue, 23 Sep 2025 21:53:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks David for pointing this out. A different instance with a different PID may have a different temp path, so the path should be specific to the instance. Since we don't need the path outside the constructor, I think we don't need to cache it. On the other hand I see that `getTempDirFromPid` is called twice, once for `.java_pid` and another time in `createAttachFile` when `.java_pid` doesn't exist. Would you suggest storing the path in a local variable in the constructor and then concatenating it with attach file name, or would a non-static member variable be more suitable for this?
>
> I would save it in a local in the constructor and pass it to `createAttachFile` rather than passing the pid.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2378277200

From jkern at openjdk.org  Thu Sep 25 09:17:09 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 25 Sep 2025 09:17:09 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v6]
In-Reply-To: <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
Message-ID: <xvFI2Hh9ofPsFbJDFEZCbO8Dq5g05jaCeSeHKM1QuTY=.6dff7d88-d7f1-4233-865c-d07503bf3094@github.com>

On Fri, 29 Aug 2025 08:56:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy 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 branch 'openjdk:master' into cpuprocessload
>  - Thread safety,struct and perfInit()
>  - Thread safety,struct and perfInit()
>  - Update ProblemList.txt
>  - Merge branch 'master' into cpuprocessload
>  - Merge branch 'master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - cleanup
>  - system cpu load
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/86d6a2e0...46dcf313

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 134:

> 132:             cpu_load = MAX(cpu_load, 0.0);
> 133:             cpu_load = MIN(cpu_load, 1.0);
> 134:             cpu_load = (user_diff + sys_diff) / delta_time;

Why is the sequence here different to the sequence in Java_com_sun_management_internal_OperatingSystemImpl_getCpuLoad0 ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2378377387

From prappo at openjdk.org  Thu Sep 25 09:28:21 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 Sep 2025 09:28:21 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <_QblLaoRLKcV6Mf8E3WFd-zpuxn3OKOUHfW0Gez7_0I=.d69c5927-075c-4008-8f62-f447816925f6@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
 <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
 <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>
 <sgelyMB-_LFjIC_qJliK7KkQJHppSN4xmI31lVD325Q=.900df29e-7114-4fa1-b879-6a06225d1f01@github.com>
 <_QblLaoRLKcV6Mf8E3WFd-zpuxn3OKOUHfW0Gez7_0I=.d69c5927-075c-4008-8f62-f447816925f6@github.com>
Message-ID: <yK3-T1rhgm6HBuNTsDCEaRIpw-LeeAA5gFjFUiF4stI=.e5072fc7-8cfc-47b4-8ea2-9716464bddd1@github.com>

On Wed, 24 Sep 2025 16:45:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> I can think of one possible wrinkle though: warnings can actually be suppressed in the source code in two ways, by `@SuppressWarnings` and by `@Deprecated` (see `Lint.suppressionsFrom(Symbol)`). So you'd also have to look for `@Deprecated`; but this also brings up the unsettling possibility that in the future, some new annotation might have a similar side-effect, and then we'd be in trouble again. So there is an aspect of this idea that requires us to make certain predictions about the future, which of course is dangerous. I think it's safer to "just say no".

`@Deprecated` as well as a conceivable future tag whose secondary effect is to silence possible warnings are very different from `@SuppressWarnings`. While I don't see why we might need to consider those underneath `@SuppressWarnings("suppression")` to decide if it should emit a warning, it's okay to say that it's safer not to complicate things. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3333072769

From schernyshev at openjdk.org  Thu Sep 25 09:36:56 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 25 Sep 2025 09:36:56 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v5]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <JDySXe8YKLNFK5ER6nkCSG_pmDmb3wirJ5ZKLQhSrfM=.c93e9741-d7cf-4825-b370-061b26d3873c@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused native method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/9ca4aaf0..4c96cca5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=03-04

  Stats: 26 lines in 2 files changed: 0 ins; 26 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25824.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25824/head:pull/25824

PR: https://git.openjdk.org/jdk/pull/25824

From schernyshev at openjdk.org  Thu Sep 25 11:22:05 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 25 Sep 2025 11:22:05 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into JDK-8319589
 - Removed unused native method
 - addressed review comment #2
 - Apply suggestions from code review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - addressed review comments
 - 8319589: Attach from root to a user java process not supported in Mac

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/4c96cca5..75dd6fb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=04-05

  Stats: 325003 lines in 5273 files changed: 226501 ins; 64752 del; 33750 mod
  Patch: https://git.openjdk.org/jdk/pull/25824.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25824/head:pull/25824

PR: https://git.openjdk.org/jdk/pull/25824

From jsjolen at openjdk.org  Thu Sep 25 12:13:32 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 25 Sep 2025 12:13:32 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
Message-ID: <np8mKw3qDSuT-S_1viDlLak4nnMnMrwuUmB6pkQg_B8=.7796826e-53b4-4224-8e10-9592750f1dcf@github.com>

On Tue, 23 Sep 2025 04:11:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>>  - Fix BSM naming
>
> src/hotspot/share/oops/constantPool.hpp line 116:
> 
>> 114:     return _argument_count;
>> 115:   }
>> 116:   int argument(int n) const {
> 
> Q: Why was the function name changed?

I think `argument_index` sounds a bit misleading, "the nth argument" makes more sense imo. Yes, I introduced the original name :-).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2378875552

From jsjolen at openjdk.org  Thu Sep 25 12:23:11 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 25 Sep 2025 12:23:11 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v8]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <7NmgdmfTkUlL6XJSOOi8QoroX0B-wYYqcrKswicgNls=.2bdc9156-c580-41b7-a2d0-1f8202d52007@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Serguei's review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/d8624f09..f96a16e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=06-07

  Stats: 15 lines in 4 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

PR: https://git.openjdk.org/jdk/pull/27198

From jsjolen at openjdk.org  Thu Sep 25 12:23:12 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 25 Sep 2025 12:23:12 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <lXnpO8MT6WKQUTvY8K8WjXAqd06ScUOghgeXgxXQ54I=.3f8e5ba0-3010-40da-8e5c-3572027102f6@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <j5moEV1aWKIQF5Zhfgqu4uzBrO6V6AzSKLcUaieZvkg=.2c79d4fb-f0af-413c-83f4-bfaeb983cd57@github.com>
 <lXnpO8MT6WKQUTvY8K8WjXAqd06ScUOghgeXgxXQ54I=.3f8e5ba0-3010-40da-8e5c-3572027102f6@github.com>
Message-ID: <DWJDKpcwMA6oZjNzLX8n5aBP22P_Mu7yvuw6KPH80Cg=.7bd6cdab-fdad-4b47-a27c-d79b5de1b4bf@github.com>

On Sat, 20 Sep 2025 05:58:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> You might want @sspitsyn  to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays.
>
>> @coleenp said: You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays.
> 
> Thanks. I'm looking at this update.

@sspitsyn , I applied most of your nits!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3333668069

From jsjolen at openjdk.org  Thu Sep 25 12:23:14 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 25 Sep 2025 12:23:14 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <TEilMfBj4quy7wrgYjqc1TsFWE6EkBdpYIrN6wj5Gkc=.b808b3fc-fc87-4208-b853-bcd926925a32@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <TEilMfBj4quy7wrgYjqc1TsFWE6EkBdpYIrN6wj5Gkc=.b808b3fc-fc87-4208-b853-bcd926925a32@github.com>
Message-ID: <gyrTFFJtTkugm_YWnZQoh9JsTJkBRCn_O3sS1DnKNas=.40281507-d3ba-464d-9198-988ac614f11f@github.com>

On Tue, 23 Sep 2025 04:30:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>>  - Fix BSM naming
>
> src/hotspot/share/oops/constantPool.hpp line 128:
> 
>> 126: 
>> 127: // The BSMAttributeEntries stores the state of the BootstrapMethods attribute.
>> 128: class BSMAttributeEntries {
> 
> Nit: I'm thinking if it would make sense to rename it to `BSMEntries`.
> Then we could rename this as well: `BSMAttributeEntry` => `BSMEntry`.
> It feels like it will increase the readability as it is already clear that `BSMEntry` is about `BSM` attributes.

Hmm, I don't want to go into renaming them in this PR. I think that's something that can be done separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2378887133

From duke at openjdk.org  Thu Sep 25 12:44:33 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 12:44:33 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v15]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <LbtKjOFGsHTibAzEPUiW9ZqBktChIHNCRguabF9NWAA=.d17d091e-79d8-40eb-b320-cd36aac1503c@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits:

 - Merge branch 'openjdk:master' into jdk-8360498
 - Removes not needed changes
 - Revert "Removes not needed changes"
   
   This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb.
 - Removes not needed changes
 - Removes extra white lines
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers missed frames in the middle of screen
 - ... and 64 more: https://git.openjdk.org/jdk/compare/26b5708c...e5753d14

-------------

Changes: https://git.openjdk.org/jdk/pull/26625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14
  Stats: 185 lines in 14 files changed: 96 ins; 44 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

PR: https://git.openjdk.org/jdk/pull/26625

From duke at openjdk.org  Thu Sep 25 13:03:51 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 13:03:51 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Resolves confict for when there is a merge with jdk-8158801

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/e5753d14..8794db9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14-15

  Stats: 55 lines in 1 file changed: 36 ins; 3 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

PR: https://git.openjdk.org/jdk/pull/26625

From alanb at openjdk.org  Thu Sep 25 13:30:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 13:30:34 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16]
In-Reply-To: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
Message-ID: <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>

On Thu, 25 Sep 2025 13:03:51 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolves confict for when there is a merge with jdk-8158801

What is this about? The PR suggests 500+ commits and 300+  files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334044893

From duke at openjdk.org  Thu Sep 25 14:00:10 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 14:00:10 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16]
In-Reply-To: <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
 <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>
Message-ID: <URXFmVJhmSe8PBZ4Vdbqw_lKQyw9TfofauV5j6QYwzA=.50d49205-a08a-4147-a97e-66f090371efc@github.com>

On Thu, 25 Sep 2025 13:26:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Resolves confict for when there is a merge with jdk-8158801
>
> What is this about? The PR suggests 500+ commits and 300+  files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists.

@AlanBateman This PR is created based on PR https://github.com/openjdk/jdk/tree/pr/25971. My branch https://github.com/kboulanou/jdk/tree/jdk-8360498 is only 2 commits behind master. I am waiting for approval for PR https://github.com/openjdk/jdk/tree/pr/25971 for this PR to follow. Please let me know if there is anything I need to do. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334251324

From duke at openjdk.org  Thu Sep 25 14:00:08 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 14:00:08 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v17]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <IFBetIfNildsjk1H900soCAiLg2EM8nsjrkfKOPWBV4=.4ccfcb8f-ec0e-4c6b-a713-c604c6a9f114@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8360498
 - 8359378: aarch64: crash when using -XX:+UseFPUForSpilling
   
   Reviewed-by: aph, rcastanedalo
 - 8367103: RISC-V: store cpu features in a bitmap
   
   Reviewed-by: fyang, luhenry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/8794db9a..69c087a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15-16

  Stats: 214 lines in 3 files changed: 142 ins; 4 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

PR: https://git.openjdk.org/jdk/pull/26625

From sroy at openjdk.org  Thu Sep 25 14:35:51 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 25 Sep 2025 14:35:51 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v7]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Update UnixOperatingSystem.c
  
  change sequence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25332/files
  - new: https://git.openjdk.org/jdk/pull/25332/files/46dcf313..55520100

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332

PR: https://git.openjdk.org/jdk/pull/25332

From sroy at openjdk.org  Thu Sep 25 14:35:56 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 25 Sep 2025 14:35:56 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v6]
In-Reply-To: <xvFI2Hh9ofPsFbJDFEZCbO8Dq5g05jaCeSeHKM1QuTY=.6dff7d88-d7f1-4233-865c-d07503bf3094@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@github.com>
 <xvFI2Hh9ofPsFbJDFEZCbO8Dq5g05jaCeSeHKM1QuTY=.6dff7d88-d7f1-4233-865c-d07503bf3094@github.com>
Message-ID: <S115Bddcjzcpy3eHxa5_UeaQoRMoZRD9wTK0aTXY4i0=.0e5a765b-10a5-41fa-a6e2-bb696eb7e549@github.com>

On Thu, 25 Sep 2025 09:13:58 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Suchismith Roy 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 branch 'openjdk:master' into cpuprocessload
>>  - Thread safety,struct and perfInit()
>>  - Thread safety,struct and perfInit()
>>  - Update ProblemList.txt
>>  - Merge branch 'master' into cpuprocessload
>>  - Merge branch 'master' into cpuprocessload
>>  - Update UnixOperatingSystem.c
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - cleanup
>>  - system cpu load
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/86d6a2e0...46dcf313
>
> src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 134:
> 
>> 132:             cpu_load = MAX(cpu_load, 0.0);
>> 133:             cpu_load = MIN(cpu_load, 1.0);
>> 134:             cpu_load = (user_diff + sys_diff) / delta_time;
> 
> Why is the sequence here different to the sequence in Java_com_sun_management_internal_OperatingSystemImpl_getCpuLoad0 ?

Thanks for catching this. Missed this detail for this method. Had kept the right logic in other one.  It does not get caught in the tests either!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2379374478

From larry.cable at oracle.com  Thu Sep 25 15:14:55 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 25 Sep 2025 08:14:55 -0700
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <tuTOeqxpBCJd5jDMbYEmMx8dkGs9-qcA73taHWf_0jY=.5ca6438c-c629-482c-90c9-10cce78536ff@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
 <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
 <tuTOeqxpBCJd5jDMbYEmMx8dkGs9-qcA73taHWf_0jY=.5ca6438c-c629-482c-90c9-10cce78536ff@github.com>
Message-ID: <c20c285c-a5eb-4c55-ab99-c1c96ba58211@oracle.com>



On 9/25/25 12:00 AM, Alan Bateman wrote:
> On Wed, 24 Sep 2025 09:09:22 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:
>
>> Do you think we would need a CSR for this kind of change?
> The output from several commands have changed over many releases/years, the output from Thread.dump in particular. AFAIK, none of these changes has a CSR, there were only CSRs when new commands were added. That said, if there is some evidence that the output is being parsed then there is a compatibility concern so creating a CSR and RN would prudent.

I am personally aware of at least one cloud svc that parses jcmd o/p 
that may be affected by such a change

>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3332451741


From lmesnik at openjdk.org  Thu Sep 25 17:12:47 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 25 Sep 2025 17:12:47 GMT
Subject: RFR: 8368699: nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp
 destroys jvmti monitor when VM is dead
Message-ID: <f8q-zytMJtnxZT-VUNJKQb3WcEyM0kqQSb1yN1sxXSw=.96f5259e-a039-4bab-8c2c-65bb544d4fb0@github.com>

Test
nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp
destroys jvmti raw monitor in incorrect phase. 

The test is not failing because currently the failure is ignored.
However I plan to fix https://bugs.openjdk.org/browse/JDK-8352654 and the test going to fails.

-------------

Commit messages:
 - 8368699: nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp destroys jvmti monitor when VM is dead

Changes: https://git.openjdk.org/jdk/pull/27495/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27495&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368699
  Stats: 12 lines in 1 file changed: 8 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27495/head:pull/27495

PR: https://git.openjdk.org/jdk/pull/27495

From fandreuzzi at openjdk.org  Thu Sep 25 17:32:27 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 25 Sep 2025 17:32:27 GMT
Subject: RFR: 8283198: Remove src/jdk.hotspot.agent/test
Message-ID: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>

According to the README, this is a manual test of `libproc.so`. The test has a non-standard structure, does not compile using the provided `Makefile`, and hasn't run possibly in a long time. Thus, I propose to remove it.

-------------

Commit messages:
 - rm

Changes: https://git.openjdk.org/jdk/pull/27496/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27496&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283198
  Stats: 408 lines in 6 files changed: 0 ins; 408 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27496.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27496/head:pull/27496

PR: https://git.openjdk.org/jdk/pull/27496

From amenkov at openjdk.org  Thu Sep 25 19:09:13 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:09:13 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v3]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <hmSQ8IzFdvbQzL070v_Y7ojzcRrMqzZty-mljypBNUQ=.da582904-f7a3-4e58-923e-aaa8a71b2ace@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/5a2a8dc7..e8715cc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

PR: https://git.openjdk.org/jdk/pull/27457

From amenkov at openjdk.org  Thu Sep 25 19:33:58 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:33:58 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v4]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <CuCEjfyczTqDMlXZFRrWd2ZUxdToVbPUO4IYJfOmFYc=.a3ec45fb-48f7-400f-9a34-4e61909112d0@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/e8715cc2..fb3d55ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=02-03

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

PR: https://git.openjdk.org/jdk/pull/27457

From amenkov at openjdk.org  Thu Sep 25 19:34:00 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:34:00 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <-VWVWqC03kK76gkiGdkn65JRZYsNALKotU0ImMU4axI=.25e58e0a-3a8e-4c6a-9280-4ca00b110879@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>
 <-VWVWqC03kK76gkiGdkn65JRZYsNALKotU0ImMU4axI=.25e58e0a-3a8e-4c6a-9280-4ca00b110879@github.com>
Message-ID: <6He4wm7RD2rsTwbL7449BhfGf2NxMrENHUhuZRr-qcQ=.b5eb75e1-7aa6-435c-9879-da935198baca@github.com>

On Thu, 25 Sep 2025 06:29:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 83:
>> 
>>> 81:                           "owner": {
>>> 82:                             "type": "string",
>>> 83:                             "description": "The thread identifier of the owner when the parkBlocker is an AbstractOwnableSynchronizer."
>> 
>> Is it possible for there to not be an owner? If so what does this report?
>
> In the schema, the only require property of a parkBlocker is "object". The "owner" is optional.

Yes, owner may be absent.
As we discussed in the JBS, owner can release the object at any time (and set "parkBlockerOwner" field to null)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380094231

From amenkov at openjdk.org  Thu Sep 25 19:34:02 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:34:02 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
 <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>
Message-ID: <bgIzt7IBbf8_HC5yDFSh2vlxWdyECYquUF43eEdmvac=.0d5dc359-c8b6-40ed-b06c-d4536e1461e6@github.com>

On Thu, 25 Sep 2025 02:02:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:
>> 
>>> 686: 
>>> 687:     /**
>>> 688:      * Returns true if lines of a plain text thread dump containing the given text.
>> 
>> Nit: Should it be: "...if lines of a plain text thread dump **is** containing" ?
>
> The original "contain" was correct. Alternatively:
>> Returns true if lines is a plain text thread dump containing the given text.

Well.. this was Alan's request to update the comment.
To me original comment was clear and correct.
@AlanBateman , what do you prefer to see here:
- Returns true if lines of a plain text thread dump contain the given text. (original)
- Returns true if lines of a plain text thread dump is containing the given text.
- Returns true if lines is a plain text thread dump containing the given text.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380081779

From amenkov at openjdk.org  Thu Sep 25 19:40:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:40:40 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/fb3d55ad..bc664ef4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

PR: https://git.openjdk.org/jdk/pull/27457

From amenkov at openjdk.org  Thu Sep 25 19:40:45 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:40:45 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <HNCpHfQDIgYoUPZ1MYH5HQh39LJ7t-w-3adgRfBHZzg=.bbb318b1-4c43-460b-a9a5-8a9183105989@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <HNCpHfQDIgYoUPZ1MYH5HQh39LJ7t-w-3adgRfBHZzg=.bbb318b1-4c43-460b-a9a5-8a9183105989@github.com>
Message-ID: <Zax25QuffcAFRfr0gJoz8Lzu3SrZ_4YGEFPbuZ2dpK4=.a4676372-e401-4198-a3da-e77bee4f0fa2@github.com>

On Thu, 25 Sep 2025 07:05:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 47:
> 
>> 45:     private int blockerTypeOrdinal;
>> 46:     private Object blockerObject;
>> 47:     // the owner of the blockerObject when the object is park blocker and is AQS
> 
> Typo here, AQS != AbstractOwnableSynchronizer

Replaced with "AbstractOwnableSynchronizer"

> src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 87:
> 
>> 85:                           "required": [
>> 86:                             "object"
>> 87:                           ]
> 
> At L122 the null in the items object should be in quotes, as in "null", and the description ending in ".. null if eliminated" needs a period. There were in the first prototype but didn't make it into the PR patch for some reason. (It came up when using the updated JSON schema, wasn't noticed previously).

Fixed

> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 445:
> 
>> 443:             assertNotNull(parkBlocker);
>> 444:             assertTrue(parkBlocker.contains("java.util.concurrent.locks.ReentrantLock"));
>> 445: 
> 
> Will you add 8365057 to the `@bug` at the top?

Done

> test/lib/jdk/test/lib/threaddump/ThreadDump.java line 300:
> 
>> 298: 
>> 299:         /**
>> 300:          * Returns the owner of the parkBlocker if the parkBlocker is an AQS.
> 
> Can you change "AQS" to AbstractOwnableSynchronizer here? It could be changed to AOS too but few will know what it means.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380140551
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380139086
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380139344
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380139864

From dlong at openjdk.org  Thu Sep 25 22:08:00 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 25 Sep 2025 22:08:00 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <QlAr_4lTaGeC_tCezdxQnOnwAeIH3qVU9yMUT7Pf9CI=.2f4f3978-d455-4a8b-8616-28b61c160dfc@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <OqHedOUnvbvpWP-wxFSQ-tT8vzpkKfndlbBzmpun-Fk=.94ced09e-0ed3-42ca-ace4-14473a97bede@github.com>
 <ug-vRNwvLtNwntH63rpqn4ZGu978VXyhTbZ2aBURrAo=.52423675-8cba-4468-8236-1d82001ff6d7@github.com>
 <QlAr_4lTaGeC_tCezdxQnOnwAeIH3qVU9yMUT7Pf9CI=.2f4f3978-d455-4a8b-8616-28b61c160dfc@github.com>
Message-ID: <vhMaN9p4NXOcXml3jjeURuw6P170lNQr5ARKkWpV5AM=.73a1c4fa-0edd-4aa3-b90e-d425c8fd7cd6@github.com>

On Thu, 25 Sep 2025 06:48:52 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> I would rather keep this code as a debug only sanity check, but I would refactor it into a single function. Then the question remains what to do with the SA code, that still does nothing.

I think we can do even better and get rid of adjust_unextended_sp, moving the debug check into get_deopt_original_pc.  This moves the SA changes into shared code, and fixes the anomaly that s390 never called adjust_unextended_sp and thus never called the debug code to do the sanity check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2380422777

From dlong at openjdk.org  Fri Sep 26 00:23:28 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 26 Sep 2025 00:23:28 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v7]
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <Mg297XMnLCHwnt0GcIs0lIYLZqhTzPJAMxtXr2WcKJI=.8d900f97-511f-4406-9411-2f117022b329@github.com>

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  more cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27059/files
  - new: https://git.openjdk.org/jdk/pull/27059/files/10668bd7..814693fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=05-06

  Stats: 361 lines in 18 files changed: 21 ins; 338 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059

PR: https://git.openjdk.org/jdk/pull/27059

From amenkov at openjdk.org  Fri Sep 26 01:13:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 01:13:32 GMT
Subject: RFR: 8283198: Remove src/jdk.hotspot.agent/test
In-Reply-To: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
References: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
Message-ID: <RzJuM_nSQ_Jj33z1xJgkDk2c5Mf-pYpEyWuiVGQRMnI=.9b27e4fd-d59f-47c7-814d-c0f41fdf2a28@github.com>

On Thu, 25 Sep 2025 17:25:08 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> According to the README, this is a manual test of `libproc.so`. The test has a non-standard structure, does not compile using the provided `Makefile`, and hasn't run possibly in a long time. Thus, I propose to remove it.

looks like it hasn't been used for ages.
And I suppose test platform was solaris

-------------

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27496#pullrequestreview-3269843503

From dlong at openjdk.org  Fri Sep 26 01:22:50 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 26 Sep 2025 01:22:50 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v8]
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <wYgzm19zsWzCkLBF1RS5YspMg1nS6e4it8-jy2d1whE=.67278ff0-7d03-4290-be9c-e2a5433a1694@github.com>

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  copyright year update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27059/files
  - new: https://git.openjdk.org/jdk/pull/27059/files/814693fa..6a1062c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=06-07

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059

PR: https://git.openjdk.org/jdk/pull/27059

From lmesnik at openjdk.org  Fri Sep 26 02:30:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 26 Sep 2025 02:30:34 GMT
Subject: RFR: 8308027:
 GetThreadListStackTraces/OneGetThreadListStackTraces.java should be skipped
 when thread factory is used
Message-ID: <f6Ib4jcUIVCHctBF7bbwmsw8_iaRaKuyawHeDdLCnH4=.136f5555-2181-4ef3-b7a5-83efb65a6a6d@github.com>

The test fails with virtual thread factory. 
There is no good way to adopt it for virtual thread factory. So let skip it's execution with it permanently.

The property support has been added to the jtregby
https://bugs.openjdk.org/browse/CODETOOLS-7903931

I use
`@requires test.thread.factory == null`
and not
`@requires test.thread.factory != "Virtual"`
because I don't think that it makes sense to run it with any potential test thread factory, like "VirtualStress"

-------------

Commit messages:
 - 8308027: GetThreadListStackTraces/OneGetThreadListStackTraces.java should be skipped when thread factory is used

Changes: https://git.openjdk.org/jdk/pull/27507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27507&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308027
  Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27507/head:pull/27507

PR: https://git.openjdk.org/jdk/pull/27507

From alanb at openjdk.org  Fri Sep 26 06:01:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Sep 2025 06:01:19 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <bgIzt7IBbf8_HC5yDFSh2vlxWdyECYquUF43eEdmvac=.0d5dc359-c8b6-40ed-b06c-d4536e1461e6@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
 <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>
 <bgIzt7IBbf8_HC5yDFSh2vlxWdyECYquUF43eEdmvac=.0d5dc359-c8b6-40ed-b06c-d4536e1461e6@github.com>
Message-ID: <4XBBUGAlktyMI3A2agyrCjlY4IKtxp1eUX8_YWSp_gI=.f9f1e32b-1a3c-4265-bafb-767211e171b5@github.com>

On Thu, 25 Sep 2025 19:08:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The original "contain" was correct. Alternatively:
>>> Returns true if lines is a plain text thread dump containing the given text.
>
> Well.. this was Alan's request to update the comment.
> To me original comment was clear and correct.
> @AlanBateman , what do you prefer to see here:
> - Returns true if lines of a plain text thread dump contain the given text. (original)
> - Returns true if lines of a plain text thread dump is containing the given text.
> - Returns true if lines is a plain text thread dump containing the given text.

Apologies, it was a typo in a separate branch used for prototype. So ignore my comment, I think left the existing comment on the test method as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380945985

From dholmes at openjdk.org  Fri Sep 26 06:12:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 26 Sep 2025 06:12:14 GMT
Subject: RFR: 8308027:
 GetThreadListStackTraces/OneGetThreadListStackTraces.java should be skipped
 when thread factory is used
In-Reply-To: <f6Ib4jcUIVCHctBF7bbwmsw8_iaRaKuyawHeDdLCnH4=.136f5555-2181-4ef3-b7a5-83efb65a6a6d@github.com>
References: <f6Ib4jcUIVCHctBF7bbwmsw8_iaRaKuyawHeDdLCnH4=.136f5555-2181-4ef3-b7a5-83efb65a6a6d@github.com>
Message-ID: <5JEpsu_Ip0MEEiP00LdEsJP-OAHlniH8cwz66S3yIPM=.4f302769-8f0b-4498-a075-36c3ee16fabe@github.com>

On Fri, 26 Sep 2025 02:23:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test fails with virtual thread factory. 
> There is no good way to adopt it for virtual thread factory. So let skip it's execution with it permanently.
> 
> The property support has been added to the jtregby
> https://bugs.openjdk.org/browse/CODETOOLS-7903931
> 
> I use
> `@requires test.thread.factory == null`
> and not
> `@requires test.thread.factory != "Virtual"`
> because I don't think that it makes sense to run it with any potential test thread factory, like "VirtualStress"

Seems reasonable. Thanks,

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27507#pullrequestreview-3270282970

From dholmes at openjdk.org  Fri Sep 26 06:17:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 26 Sep 2025 06:17:28 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
Message-ID: <Dzz5arqrg_flpzwNUpFue4GGnkSC1cSY_m7sWDRGiHY=.e190cf5d-3238-437b-b1e2-1407b516490b@github.com>

On Thu, 25 Sep 2025 11:22:05 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8319589
>  - Removed unused native method
>  - addressed review comment #2
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments
>  - 8319589: Attach from root to a user java process not supported in Mac

Thanks for the update. Nothing further from me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25824#pullrequestreview-3270306288

From alanb at openjdk.org  Fri Sep 26 06:31:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Sep 2025 06:31:15 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
Message-ID: <99K6laRc0VAmj4SpVQUMyFFqGNa2pRr3s-b6atp8jzE=.fd9bb67e-5902-4bfc-aef5-2e8b9c256581@github.com>

On Thu, 25 Sep 2025 19:40:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Aside from the issues with the method comments in the DumpThreads test, I think this is okay and I don't have other comments.

As per the discussion in the JBS issue, it's still a bit icky to read this field when all access is plain access, but it may be useful for diagnosing hangs and deadlocks.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3270352643

From mhaessig at openjdk.org  Fri Sep 26 07:17:20 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 26 Sep 2025 07:17:20 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v8]
In-Reply-To: <wYgzm19zsWzCkLBF1RS5YspMg1nS6e4it8-jy2d1whE=.67278ff0-7d03-4290-be9c-e2a5433a1694@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <wYgzm19zsWzCkLBF1RS5YspMg1nS6e4it8-jy2d1whE=.67278ff0-7d03-4290-be9c-e2a5433a1694@github.com>
Message-ID: <VSiFSTBWQHe-Bt02ii1D898oM9afz0Mt8UZcFH7XOwY=.b32d834d-e52d-4db2-b8bc-3b7384301823@github.com>

On Fri, 26 Sep 2025 01:22:50 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year update

I have one last nit below. Otherwise, this looks good to me.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java line 85:

> 83: 
> 84:   protected void adjustForDeopt() {
> 85:     if ( pc != null) {

Suggestion:

    if (pc != null) {

-------------

Marked as reviewed by mhaessig (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3270357612
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2381017332

From mhaessig at openjdk.org  Fri Sep 26 07:17:21 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 26 Sep 2025 07:17:21 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <vhMaN9p4NXOcXml3jjeURuw6P170lNQr5ARKkWpV5AM=.73a1c4fa-0edd-4aa3-b90e-d425c8fd7cd6@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <OqHedOUnvbvpWP-wxFSQ-tT8vzpkKfndlbBzmpun-Fk=.94ced09e-0ed3-42ca-ace4-14473a97bede@github.com>
 <ug-vRNwvLtNwntH63rpqn4ZGu978VXyhTbZ2aBURrAo=.52423675-8cba-4468-8236-1d82001ff6d7@github.com>
 <QlAr_4lTaGeC_tCezdxQnOnwAeIH3qVU9yMUT7Pf9CI=.2f4f3978-d455-4a8b-8616-28b61c160dfc@github.com>
 <vhMaN9p4NXOcXml3jjeURuw6P170lNQr5ARKkWpV5AM=.73a1c4fa-0edd-4aa3-b90e-d425c8fd7cd6@github.com>
Message-ID: <aMNEwbM7LdvL0Pp78A-R5_in7mxNUzYKQDcPyMqtlv4=.21d406cb-d2dc-4df4-99b2-c382aabca307@github.com>

On Thu, 25 Sep 2025 22:05:10 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I would rather keep this code as a debug only sanity check, but I would refactor it into a single function. Then the question remains what to do with the SA code, that still does nothing.
>
>> I would rather keep this code as a debug only sanity check, but I would refactor it into a single function. Then the question remains what to do with the SA code, that still does nothing.
> 
> I think we can do even better and get rid of adjust_unextended_sp, moving the debug check into get_deopt_original_pc.  This moves the SA changes into shared code, and fixes the anomaly that s390 never called adjust_unextended_sp and thus never called the debug code to do the sanity check.

That is indeed even better. Nice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2381117772

From sspitsyn at openjdk.org  Fri Sep 26 07:24:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 07:24:26 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
Message-ID: <qV_ePYy93VPsUshcIc9P5SribMETeShF7BmyVQN1kbA=.05f17d3b-31df-4f06-9ba8-93a7bf92323d@github.com>

On Thu, 25 Sep 2025 19:40:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Just one simple comment update is still needed. Otherwise, it is good.

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:

> 686: 
> 687:     /**
> 688:      * Returns true if lines of a plain text thread dump containing the given text.

Nit: This still needs to be reverted back.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3270528351
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2381135179

From sspitsyn at openjdk.org  Fri Sep 26 07:26:31 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 07:26:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <gyrTFFJtTkugm_YWnZQoh9JsTJkBRCn_O3sS1DnKNas=.40281507-d3ba-464d-9198-988ac614f11f@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <TEilMfBj4quy7wrgYjqc1TsFWE6EkBdpYIrN6wj5Gkc=.b808b3fc-fc87-4208-b853-bcd926925a32@github.com>
 <gyrTFFJtTkugm_YWnZQoh9JsTJkBRCn_O3sS1DnKNas=.40281507-d3ba-464d-9198-988ac614f11f@github.com>
Message-ID: <ju_FTYh8VnnpzfIabA-d2eBiydCuMc6Oa9okVz6k55U=.f0911423-85ee-4db7-a8a2-17aa0a91a91f@github.com>

On Thu, 25 Sep 2025 12:15:42 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/oops/constantPool.hpp line 128:
>> 
>>> 126: 
>>> 127: // The BSMAttributeEntries stores the state of the BootstrapMethods attribute.
>>> 128: class BSMAttributeEntries {
>> 
>> Nit: I'm thinking if it would make sense to rename it to `BSMEntries`.
>> Then we could rename this as well: `BSMAttributeEntry` => `BSMEntry`.
>> It feels like it will increase the readability as it is already clear that `BSMEntry` is about `BSM` attributes.
>
> Hmm, I don't want to go into renaming them in this PR. I think that's something that can be done separately.

Why not? This PR is introducing these two classes. It is better to do in a simplified form. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2381144985

From ayang at openjdk.org  Fri Sep 26 07:32:26 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 26 Sep 2025 07:32:26 GMT
Subject: RFR: 8283198: Remove src/jdk.hotspot.agent/test
In-Reply-To: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
References: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
Message-ID: <yMmM7hUKAuAR5sz_SkHDwttNBq6NqyybExXhMZVyoyY=.869b406b-d32b-4414-bd79-38f8b070f3a0@github.com>

On Thu, 25 Sep 2025 17:25:08 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> According to the README, this is a manual test of `libproc.so`. The test has a non-standard structure, does not compile using the provided `Makefile`, and hasn't run possibly in a long time. Thus, I propose to remove it.

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27496#pullrequestreview-3270569290

From sspitsyn at openjdk.org  Fri Sep 26 07:39:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 07:39:30 GMT
Subject: RFR: 8308027:
 GetThreadListStackTraces/OneGetThreadListStackTraces.java should be skipped
 when thread factory is used
In-Reply-To: <f6Ib4jcUIVCHctBF7bbwmsw8_iaRaKuyawHeDdLCnH4=.136f5555-2181-4ef3-b7a5-83efb65a6a6d@github.com>
References: <f6Ib4jcUIVCHctBF7bbwmsw8_iaRaKuyawHeDdLCnH4=.136f5555-2181-4ef3-b7a5-83efb65a6a6d@github.com>
Message-ID: <USenwwGMA55BnkhJ-_lS80Lq-AgH8o79Xg5kCqsgtcI=.55caac63-fd02-4449-b51f-0378840b91c7@github.com>

On Fri, 26 Sep 2025 02:23:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test fails with virtual thread factory. 
> There is no good way to adopt it for virtual thread factory. So let skip it's execution with it permanently.
> 
> The property support has been added to the jtregby
> https://bugs.openjdk.org/browse/CODETOOLS-7903931
> 
> I use
> `@requires test.thread.factory == null`
> and not
> `@requires test.thread.factory != "Virtual"`
> because I don't think that it makes sense to run it with any potential test thread factory, like "VirtualStress"

Looks reasonable.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27507#pullrequestreview-3270605728

From sspitsyn at openjdk.org  Fri Sep 26 07:42:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 07:42:27 GMT
Subject: RFR: 8283198: Remove src/jdk.hotspot.agent/test
In-Reply-To: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
References: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
Message-ID: <2unes25li0PgkIBazi38IJCPBJgyGRrVIU6ykFzn6jc=.1792e07f-d031-4bd5-8dca-fe1c2f794b77@github.com>

On Thu, 25 Sep 2025 17:25:08 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> According to the README, this is a manual test of `libproc.so`. The test has a non-standard structure, does not compile using the provided `Makefile`, and hasn't run possibly in a long time. Thus, I propose to remove it.

Looks reasonable.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27496#pullrequestreview-3270614252

From sspitsyn at openjdk.org  Fri Sep 26 07:53:22 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 07:53:22 GMT
Subject: RFR: 8368699:
 nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp destroys jvmti monitor
 when VM is dead
In-Reply-To: <f8q-zytMJtnxZT-VUNJKQb3WcEyM0kqQSb1yN1sxXSw=.96f5259e-a039-4bab-8c2c-65bb544d4fb0@github.com>
References: <f8q-zytMJtnxZT-VUNJKQb3WcEyM0kqQSb1yN1sxXSw=.96f5259e-a039-4bab-8c2c-65bb544d4fb0@github.com>
Message-ID: <f4omRa3AKaf8wXBlF4XDFvvfqApW1_GySmE9TLyau3s=.4df30578-df8a-44be-95d5-f5f8a3849d5c@github.com>

On Thu, 25 Sep 2025 17:06:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test
> nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp
> destroys jvmti raw monitor in incorrect phase. 
> 
> The test is not failing because currently the failure is ignored.
> However I plan to fix https://bugs.openjdk.org/browse/JDK-8352654 and the test going to fails.

Looks good. It is interesting that VM_DEATH event was already enabled for this test. :)

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27495#pullrequestreview-3270660021

From sspitsyn at openjdk.org  Fri Sep 26 07:58:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 07:58:41 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <lXnpO8MT6WKQUTvY8K8WjXAqd06ScUOghgeXgxXQ54I=.3f8e5ba0-3010-40da-8e5c-3572027102f6@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <j5moEV1aWKIQF5Zhfgqu4uzBrO6V6AzSKLcUaieZvkg=.2c79d4fb-f0af-413c-83f4-bfaeb983cd57@github.com>
 <lXnpO8MT6WKQUTvY8K8WjXAqd06ScUOghgeXgxXQ54I=.3f8e5ba0-3010-40da-8e5c-3572027102f6@github.com>
Message-ID: <2JW3Vh4F955tssSaTblMWKVVizigJPzftJIPyWnICKk=.b1ebe02a-38fc-4965-a46a-30b8a13c8a83@github.com>

On Sat, 20 Sep 2025 05:58:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> You might want @sspitsyn  to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays.
>
>> @coleenp said: You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays.
> 
> Thanks. I'm looking at this update.

> @sspitsyn , I applied most of your nits!

Thanks!
In fact, I like your refactoring but it'd be nice to make names right and consistent. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3337225511

From sspitsyn at openjdk.org  Fri Sep 26 08:02:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 08:02:57 GMT
Subject: RFR: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing [v2]
In-Reply-To: <zX-c8zkKFhNyOgDEvolme0OApFyIW6HjQEkAqe5TRog=.602a87ab-d449-4d6b-a848-76123f87581c@github.com>
References: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
 <zX-c8zkKFhNyOgDEvolme0OApFyIW6HjQEkAqe5TRog=.602a87ab-d449-4d6b-a848-76123f87581c@github.com>
Message-ID: <5Aw6HLQtgXmPOuTeevkLPNHJaf1phPP4HpG7yKK86MA=.04ffefcc-b9f7-4f54-aa73-dc9717336b7c@github.com>

On Wed, 24 Sep 2025 23:32:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fixed an issue with a race with two events coming in close to the same time, the first of which does not suspend any debuggee threads. More details in the first comment.
>> 
>> Tested by running all vmTestbase/nsk/jdi tests 25x times on all platforms both with and w/o virtual threads. Also ran all tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unneeded synchronized

Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27370#pullrequestreview-3270710540

From jsjolen at openjdk.org  Fri Sep 26 10:20:48 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 26 Sep 2025 10:20:48 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <ju_FTYh8VnnpzfIabA-d2eBiydCuMc6Oa9okVz6k55U=.f0911423-85ee-4db7-a8a2-17aa0a91a91f@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <TEilMfBj4quy7wrgYjqc1TsFWE6EkBdpYIrN6wj5Gkc=.b808b3fc-fc87-4208-b853-bcd926925a32@github.com>
 <gyrTFFJtTkugm_YWnZQoh9JsTJkBRCn_O3sS1DnKNas=.40281507-d3ba-464d-9198-988ac614f11f@github.com>
 <ju_FTYh8VnnpzfIabA-d2eBiydCuMc6Oa9okVz6k55U=.f0911423-85ee-4db7-a8a2-17aa0a91a91f@github.com>
Message-ID: <kyvxF6Ha8z3b-U7Gl6pDr3c5NVzPD_zyrxaNN0BnGJ8=.d1d31984-8494-4164-9298-afae1d3c2bc3@github.com>

On Fri, 26 Sep 2025 07:23:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Hmm, I don't want to go into renaming them in this PR. I think that's something that can be done separately.
>
> Why not? This PR is introducing these two classes. It is better to do in a simplified form. :)

It's only introducing the BSMAttributeEntries class, the other one is pre-existing. I don't want the PR to get stuck on whether or not to do a rename of something previously determined to be fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2381835382

From duke at openjdk.org  Fri Sep 26 15:07:05 2025
From: duke at openjdk.org (duke)
Date: Fri, 26 Sep 2025 15:07:05 GMT
Subject: RFR: 8283198: Remove src/jdk.hotspot.agent/test
In-Reply-To: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
References: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
Message-ID: <AOYVrFnxp5rhT52QKzwct3FCeAtue5qAhlNF6YmI5gI=.581464a4-d33b-420a-997e-a46f37ee0601@github.com>

On Thu, 25 Sep 2025 17:25:08 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> According to the README, this is a manual test of `libproc.so`. The test has a non-standard structure, does not compile using the provided `Makefile`, and hasn't run possibly in a long time. Thus, I propose to remove it.

@fandreuz 
Your change (at version 715bea264a4a722572b74e999c5309becb274d63) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27496#issuecomment-3339088572

From fandreuzzi at openjdk.org  Fri Sep 26 15:07:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 26 Sep 2025 15:07:05 GMT
Subject: RFR: 8283198: Remove src/jdk.hotspot.agent/test
In-Reply-To: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
References: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
Message-ID: <o4nqJ3pwixPt1-FhftsMf_kxaxcGybMlt3eCjL1hcAU=.5f3e7843-afc3-4224-b909-8114dc11edb6@github.com>

On Thu, 25 Sep 2025 17:25:08 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> According to the README, this is a manual test of `libproc.so`. The test has a non-standard structure, does not compile using the provided `Makefile`, and hasn't run possibly in a long time. Thus, I propose to remove it.

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27496#issuecomment-3339086326

From amenkov at openjdk.org  Fri Sep 26 19:05:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 19:05:35 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <qV_ePYy93VPsUshcIc9P5SribMETeShF7BmyVQN1kbA=.05f17d3b-31df-4f06-9ba8-93a7bf92323d@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
 <qV_ePYy93VPsUshcIc9P5SribMETeShF7BmyVQN1kbA=.05f17d3b-31df-4f06-9ba8-93a7bf92323d@github.com>
Message-ID: <PipknE4_c6ETRhMkBPMxUhl3braANS3e4xPFDpAv8DQ=.91df2314-f53f-4600-bc54-5f0f4e31a773@github.com>

On Fri, 26 Sep 2025 07:20:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:
> 
>> 686: 
>> 687:     /**
>> 688:      * Returns true if lines of a plain text thread dump containing the given text.
> 
> Nit: This still needs to be reverted back.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2383242806

From sspitsyn at openjdk.org  Fri Sep 26 19:19:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 19:19:24 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v6]
In-Reply-To: <Y5LHDlWvY2IGR3AsGOUvLk9d-QVnCTnf-GAw5grSpJ4=.6a1a8f6d-b4f5-49c3-bca0-ff7b17d9833f@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <Y5LHDlWvY2IGR3AsGOUvLk9d-QVnCTnf-GAw5grSpJ4=.6a1a8f6d-b4f5-49c3-bca0-ff7b17d9833f@github.com>
Message-ID: <etXxraj3IIaQ0VLwwgB2u-uGCGFfopkpjrR7hQz6lgQ=.e18358d0-5f8a-447b-9ec5-716ee2d1898b@github.com>

On Fri, 26 Sep 2025 19:05:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted comment

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3273600528

From amenkov at openjdk.org  Fri Sep 26 19:05:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 19:05:32 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v6]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <Y5LHDlWvY2IGR3AsGOUvLk9d-QVnCTnf-GAw5grSpJ4=.6a1a8f6d-b4f5-49c3-bca0-ff7b17d9833f@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  reverted comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/bc664ef4..f588a6da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

PR: https://git.openjdk.org/jdk/pull/27457

From lmesnik at openjdk.org  Fri Sep 26 19:39:24 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 26 Sep 2025 19:39:24 GMT
Subject: Integrated: 8368699:
 nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp destroys jvmti monitor
 when VM is dead
In-Reply-To: <f8q-zytMJtnxZT-VUNJKQb3WcEyM0kqQSb1yN1sxXSw=.96f5259e-a039-4bab-8c2c-65bb544d4fb0@github.com>
References: <f8q-zytMJtnxZT-VUNJKQb3WcEyM0kqQSb1yN1sxXSw=.96f5259e-a039-4bab-8c2c-65bb544d4fb0@github.com>
Message-ID: <PkiKHsHI5jLqLEPC6nebUOlT9OKqp9sqCpQSaQWrAM0=.de98f577-a8ec-4641-808d-b8e88bba4c14@github.com>

On Thu, 25 Sep 2025 17:06:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test
> nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp
> destroys jvmti raw monitor in incorrect phase. 
> 
> The test is not failing because currently the failure is ignored.
> However I plan to fix https://bugs.openjdk.org/browse/JDK-8352654 and the test going to fails.

This pull request has now been integrated.

Changeset: 62cc3472
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62cc347242ddbc8b51f023c288d78785b128e421
Stats:     12 lines in 1 file changed: 8 ins; 3 del; 1 mod

8368699: nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp destroys jvmti monitor when VM is dead

Reviewed-by: sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/27495

From lmesnik at openjdk.org  Fri Sep 26 19:37:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 26 Sep 2025 19:37:25 GMT
Subject: Integrated: 8308027:
 GetThreadListStackTraces/OneGetThreadListStackTraces.java should be skipped
 when thread factory is used
In-Reply-To: <f6Ib4jcUIVCHctBF7bbwmsw8_iaRaKuyawHeDdLCnH4=.136f5555-2181-4ef3-b7a5-83efb65a6a6d@github.com>
References: <f6Ib4jcUIVCHctBF7bbwmsw8_iaRaKuyawHeDdLCnH4=.136f5555-2181-4ef3-b7a5-83efb65a6a6d@github.com>
Message-ID: <U8-sRGxZleVtizemtDcsiokPTGd81x2xN1fKwyGzTkg=.dc4c25cb-4ec6-4b63-b645-6aa81074e931@github.com>

On Fri, 26 Sep 2025 02:23:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test fails with virtual thread factory. 
> There is no good way to adopt it for virtual thread factory. So let skip it's execution with it permanently.
> 
> The property support has been added to the jtregby
> https://bugs.openjdk.org/browse/CODETOOLS-7903931
> 
> I use
> `@requires test.thread.factory == null`
> and not
> `@requires test.thread.factory != "Virtual"`
> because I don't think that it makes sense to run it with any potential test thread factory, like "VirtualStress"

This pull request has now been integrated.

Changeset: 556dfdda
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/556dfddac82f69b8a3d3730d05fcd00e49b84f2e
Stats:     3 lines in 2 files changed: 1 ins; 1 del; 1 mod

8308027: GetThreadListStackTraces/OneGetThreadListStackTraces.java should be skipped when thread factory is used

Reviewed-by: dholmes, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/27507

From fandreuzzi at openjdk.org  Fri Sep 26 19:54:27 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 26 Sep 2025 19:54:27 GMT
Subject: Integrated: 8283198: Remove src/jdk.hotspot.agent/test
In-Reply-To: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
References: <ydRcgpdWVHSj_msycgY7_FO_Z3VD1WDUeuBTDNOQgNg=.79116dcc-585f-4819-aa97-c7294abb0e23@github.com>
Message-ID: <0ZWehdfL9q1IWkfYDxyhCNGnJE5tldejRLBVlgIfxxA=.c366d808-f3d8-429d-a284-8606e0120837@github.com>

On Thu, 25 Sep 2025 17:25:08 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> According to the README, this is a manual test of `libproc.so`. The test has a non-standard structure, does not compile using the provided `Makefile`, and hasn't run possibly in a long time. Thus, I propose to remove it.

This pull request has now been integrated.

Changeset: c6cecc58
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6cecc581f331dc61af0df2dfd5d7e0d523f6b61
Stats:     408 lines in 6 files changed: 0 ins; 408 del; 0 mod

8283198: Remove src/jdk.hotspot.agent/test

Reviewed-by: amenkov, ayang, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/27496

From dlong at openjdk.org  Fri Sep 26 20:07:36 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 26 Sep 2025 20:07:36 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v9]
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java
  
  Co-authored-by: Manuel H?ssig <manuel at haessig.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27059/files
  - new: https://git.openjdk.org/jdk/pull/27059/files/6a1062c3..d25872bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059

PR: https://git.openjdk.org/jdk/pull/27059

From dlong at openjdk.org  Fri Sep 26 20:07:38 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 26 Sep 2025 20:07:38 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v8]
In-Reply-To: <VSiFSTBWQHe-Bt02ii1D898oM9afz0Mt8UZcFH7XOwY=.b32d834d-e52d-4db2-b8bc-3b7384301823@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <wYgzm19zsWzCkLBF1RS5YspMg1nS6e4it8-jy2d1whE=.67278ff0-7d03-4290-be9c-e2a5433a1694@github.com>
 <VSiFSTBWQHe-Bt02ii1D898oM9afz0Mt8UZcFH7XOwY=.b32d834d-e52d-4db2-b8bc-3b7384301823@github.com>
Message-ID: <1CWxUjvyzz0_hlfrZW59H39VziO7_AyhCw4ZfIyUZbA=.1b88957c-2a85-4082-b210-c193340b2e9b@github.com>

On Fri, 26 Sep 2025 07:14:08 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright year update
>
> I have one last nit below. Otherwise, this looks good to me.

Thanks @mhaessig for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3340311259

From amenkov at openjdk.org  Fri Sep 26 20:52:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 20:52:40 GMT
Subject: Integrated: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <QjOZIt0Ydlb7DmgAItQeuf83Q9aOzUqgELPHvciMr44=.b577ef3a-2f60-4444-8600-d1d5025cb542@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

This pull request has now been integrated.

Changeset: cedc0117
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cedc0117ac36243cc240e8ab6adb3c78af4055fc
Stats:     78 lines in 6 files changed: 65 ins; 0 del; 13 mod

8365057: Add support for java.util.concurrent lock information to Thread.dump_to_file

Co-authored-by: Alex Menkov <amenkov at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: sspitsyn, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/27457

From lmesnik at openjdk.org  Sat Sep 27 03:43:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 27 Sep 2025 03:43:56 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
Message-ID: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>

The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
`The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`

However, current implementation changes state and only after this start disabling events.  

It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654

The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed  change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion.

After this fix the VMDeath callback also can't generate any events. 
The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion.

It might be still possible also to wait while all currently executing  events are completed. It is not required be specification, might add unneeded complexity. So  I want to apply this fix first and then to check if we still any problems.
Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout.
Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

-------------

Commit messages:
 - 8355631: The events might be generated after VM_DEATH event

Changes: https://git.openjdk.org/jdk/pull/27504/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355631
  Stats: 17 lines in 2 files changed: 14 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27504/head:pull/27504

PR: https://git.openjdk.org/jdk/pull/27504

From lmesnik at openjdk.org  Sat Sep 27 03:48:20 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 27 Sep 2025 03:48:20 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <6IQFYfD6ppX24q8JU6tEu1X1CC6slKqkyKRRbbKIr-M=.64213037-af7b-4546-a3d3-4ca078c32b17@github.com>

On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed  change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion.
> 
> After this fix the VMDeath callback also can't generate any events. 
> The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion.
> 
> It might be still possible also to wait while all currently executing  events are completed. It is not required be specification, might add unneeded complexity. So  I want to apply this fix first and then to check if we still any problems.
> Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout.
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

Note, the `_execution_finished ` is updated with `JvmtiThreadState_lock`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3341119379

From duke at openjdk.org  Sat Sep 27 17:04:33 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sat, 27 Sep 2025 17:04:33 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
Message-ID: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>

Hi all,

This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.

`CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.

FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.

Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

-------------

Commit messages:
 - Remove extra new line
 - Add GC CPU MXBeans

Changes: https://git.openjdk.org/jdk/pull/27537/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368527
  Stats: 146 lines in 11 files changed: 142 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From alanb at openjdk.org  Sat Sep 27 17:04:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 Sep 2025 17:04:33 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <J1rH0a8cRJE-XdO109GaqeaKkpS91hp0ooMUNFWAonY=.493f0a85-23ba-464a-99e1-704f94b89cf1@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

This proposal will probably require discussion as to whether this is a property of a standard MXBean or a JDK-specific MXBean. It might be that GarbageCollectorMXBean is a better place for this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3341792562

From duke at openjdk.org  Sat Sep 27 17:04:34 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sat, 27 Sep 2025 17:04:34 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <J1rH0a8cRJE-XdO109GaqeaKkpS91hp0ooMUNFWAonY=.493f0a85-23ba-464a-99e1-704f94b89cf1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <J1rH0a8cRJE-XdO109GaqeaKkpS91hp0ooMUNFWAonY=.493f0a85-23ba-464a-99e1-704f94b89cf1@github.com>
Message-ID: <Br_jY1jQZCwL7kw3X6mV7HxLRpbCT6eOYEH_95oDPzI=.6fb44cbc-3a02-465d-af0d-9d15e7fbce21@github.com>

On Sat, 27 Sep 2025 14:13:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> This proposal will probably require discussion as to whether this is a property of a standard MXBean or a JDK-specific MXBean. It might be that GarbageCollectorMXBean is a better place for this.

Thanks @AlanBateman. I did first consider `GarbageCollectorMXBean` but given that this interface only exposes a sub-component of the GC at a time it might not fit in well with a systemic method that samples the total GC CPU time.

To clarify what I mean with "exposing a sub-component at a time"; consider the following

List<GarbageCollectorMXBean> list = java.lang.management.ManagementFactory.getGarbageCollectorMXBeans();
for (GarbageCollectorMXBean gcMXBean : list) {
     System.out.println(gcMXBean.getName());
}

Its output will be

$ java -XX:+UseSerialGC Main.java
Copy
MarkSweepCompact

$ java -XX:+UseParallelGC Main.java
PS MarkSweep
PS Scavenge

 java -XX:+UseG1GC Main.java
G1 Young Generation
G1 Concurrent GC
G1 Old Generation

$ java -XX:+UseZGC Main.java
ZGC Minor Cycles
ZGC Minor Pauses
ZGC Major Cycles
ZGC Major Pauses


So no `GarbageCollectorMXBean` for any collector would map nicely to a systemic method like `getGcCpuTime()`. I could be wrong but I don't think there will be many use cases where a user wants/needs to know CPU time per each GC component nor does we currently support such granularity. If we look at the API for `MemoryMXBean` (https://docs.oracle.com/en/java/javase/25/docs/api/java.management/java/lang/management/MemoryMXBean.html) we can se that it do already include a couple of methods to query a "systemic property":

* `getHeapMemoryUsage()`
* `getNonHeapMemoryUsage()`

Additionally it includes a method to request a GC, which made me think that this could be a good fit for this method. That being said if my above observations are incorrect or there is a more appropriate place to put this method I'm happy to update the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3341917745

From sspitsyn at openjdk.org  Sun Sep 28 09:04:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 28 Sep 2025 09:04:55 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v10]
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <cM3XfHVvlvfj9zGw7tYIz5AL3IcpTSUQqcmOXLr7WqQ=.d7f4bc8a-badc-470a-b40f-9626e5a3dba5@github.com>

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 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 10 additional commits since the last revision:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - review: replace RESERVED flag with UNUSED
 - review: keep right order of the obsoleted VM options
 - corrected one assert message
 - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26232/files
  - new: https://git.openjdk.org/jdk/pull/26232/files/70a595aa..8af14e76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=08-09

  Stats: 152168 lines in 1493 files changed: 127924 ins; 14723 del; 9521 mod
  Patch: https://git.openjdk.org/jdk/pull/26232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232

PR: https://git.openjdk.org/jdk/pull/26232

From acobbs at openjdk.org  Sun Sep 28 18:56:01 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 28 Sep 2025 18:56:01 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v2]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <5Yc8i9GJZU7D_rezsZX5g6ud_5AIs0sNeFf3pf-fA-E=.0585ea54-97f0-4a54-831f-3239ae1386ae@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 131 commits:

 - 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.
 - Remove unnecessary -Xlint:-suppression flags.
 - Minor cleanups.
 - Add OPTIONS, PATH, and SUPPRESSION to the regression test.
 - Minor regression test cleanups.
 - ... and 121 more: https://git.openjdk.org/jdk/compare/9093d3a0...7714095d

-------------

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=01
  Stats: 1658 lines in 33 files changed: 1485 ins; 49 del; 124 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 fandreuzzi at openjdk.org  Sun Sep 28 21:19:42 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sun, 28 Sep 2025 21:19:42 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v6]
In-Reply-To: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
Message-ID: <0_Btanzpu7MBuR8O5THxlgtBWB7ixaabMQHvbtFpJKQ=.9d4d65a6-037d-4f04-b9fe-802c21a70c16@github.com>

> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
> 
> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
> 
> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
> 
> I added some files to the ticket for context.
> 
> Passes `tier1` and `tier2`.

Francesco Andreuzzi 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 11 additional commits since the last revision:

 - new check
 - Merge branch 'master' into JDK-8367609
 - nn
 - comment and rename
 - invert
 - review
 - simplify
 - fix
 - simple fix
 - fix
 - ... and 1 more: https://git.openjdk.org/jdk/compare/441f27be...70eaa2bb

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27274/files
  - new: https://git.openjdk.org/jdk/pull/27274/files/0a5ef012..70eaa2bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27274&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27274&range=04-05

  Stats: 151260 lines in 1486 files changed: 127279 ins; 14509 del; 9472 mod
  Patch: https://git.openjdk.org/jdk/pull/27274.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27274/head:pull/27274

PR: https://git.openjdk.org/jdk/pull/27274

From fandreuzzi at openjdk.org  Sun Sep 28 21:19:43 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sun, 28 Sep 2025 21:19:43 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <WCa4dCTYFTTzGZtzK25Nk45fclccvMG3vU_KpivOrig=.c5785f6c-3b08-4004-8b6a-66db33853740@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
 <WCa4dCTYFTTzGZtzK25Nk45fclccvMG3vU_KpivOrig=.c5785f6c-3b08-4004-8b6a-66db33853740@github.com>
Message-ID: <AKtb1Ga6kBFfrLS_yP1WFBqkGyZqJPxBHH8YRSozBQg=.f57b0f77-e36e-4a0c-98e6-6186f1641c3f@github.com>

On Tue, 23 Sep 2025 14:24:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - nn
>>  - comment and rename
>
> Thanks for the additional info.
> 
> If I ignore what's said so far and start again, I see the following...  (anyone should feel free to correct, we aren't in this
> area every day!...)
> 
> hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5)
> 
>           print_error("address conflict @ 0x%lx (existing map size = %ld, size = %ld, flags = %d)\n",
>                         target_vaddr, existing_map->memsz, lib_php->p_memsz, lib_php->p_flags);
> 
> core has no mapping at exactly 0x7fa9ff0e4440 but has:
> 
>   Start                 End               Page Offset
>   0x00007fa9ff0db000  0x00007fa9ff0e4000  0x0000000000000000 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so  (0x9000 size) 0x841c rounded up
>   0x00007fa9ff0e4000  0x00007fa9ff0fd000  0x0000000000000008 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so (0x19000 size) the existing map size from the error
>   
> 
> The error is having a size 0x17c30 mapping that should go at 0x00007fa9ff0e4000
> That is the second LOAD phdr from libjimage.
> 
> The check which has been working for gcc builds:
> ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size)
> 
> 102400 	= 0x19000 is mem size, page size aligned. The core has a mapping of this size.
> 97328	= 0x17c30 libjimage has this, which rounds up to only 0x18000
> 
> libjimage is providing too little data? 
> But target vaddr 0x7fa9ff0e4440 is offset into the actual segment 0x00007fa9ff0e4000 by  0x440  (1088 bytes)
> 
> 0x17c30 + 0x440 = 0x18070 which rounds up to the wanted 0x19000
> 
> 
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
> 
> 399       uintptr_t target_vaddr = lib_php->p_vaddr + lib_base;
> 400       map_info *existing_map = core_lookup(ph, target_vaddr);
> 
> (Existing code expects target_vaddr and existing_map->vaddr to be exactly equal, not to see target_vaddr being
> anything other than 0x1000 aligned.)
> 
> Maybe we:
> check if target_vaddr > existing_map->vaddr and add any difference to the library mem size we compare?
> 
> 
> 429             (ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size))) {
> 
> +        uint64_t lib_memsz = lib_php->p_memsz; // check type
> +        if (target_vaddr > existing_map->vaddr) {
> +            lib_memsz += (target_vaddr - existing_map->vaddr);
> +        }
> +        lib_memsz = ROUNDUP(lib_memsz, page_size);
> +
>          if ((existing_map->memsz != page_size) &&
>              (existing_map->fd != lib_fd) &&
> -            (ROUNDUP(existing_map->memsz, page_s...

Hi @kevinjwalls, what you say makes sense to me. I tried the updated check on my environment and it fixed the problem as well as what I initially proposed in this PR. 

I updated the PR too, the new check looks cleaner than what I had.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3344262943

From dholmes at openjdk.org  Mon Sep 29 01:36:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 Sep 2025 01:36:22 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3344548511

From dholmes at openjdk.org  Mon Sep 29 04:48:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 Sep 2025 04:48:17 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v8]
In-Reply-To: <7NmgdmfTkUlL6XJSOOi8QoroX0B-wYYqcrKswicgNls=.2bdc9156-c580-41b7-a2d0-1f8202d52007@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <7NmgdmfTkUlL6XJSOOi8QoroX0B-wYYqcrKswicgNls=.2bdc9156-c580-41b7-a2d0-1f8202d52007@github.com>
Message-ID: <edDtxo0z-tDGvIiUWWINPfqoLf8rk0g3jg4DqftR5K0=.58d96afc-e296-4ce2-b234-ad5d36b8b1dd@github.com>

On Thu, 25 Sep 2025 12:23:11 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Serguei's review

Updates look good. A couple of minor nits spotted.

src/hotspot/share/oops/constantPool.cpp line 761:

> 759:   if (!(which >= 0 && which < cpool->resolved_method_entries_length())) {
> 760:     // FIXME: should be an assert
> 761:     log_debug(class, resolve)("bad bsm %d in:", which); cpool->print();

Suggestion:

    log_debug(class, resolve)("bad BSM %d in:", which); cpool->print();

src/hotspot/share/oops/constantPool.cpp line 2303:

> 2301:   st->print("constant pool [%d]", length());
> 2302:   if (has_preresolution()) st->print("/preresolution");
> 2303:   if (!bsm_entries().is_empty())  st->print("/bsms[%d]", bsm_entries().bootstrap_methods()->length());

Suggestion:

  if (!bsm_entries().is_empty())  st->print("/BSMs[%d]", bsm_entries().bootstrap_methods()->length());

src/hotspot/share/oops/constantPool.cpp line 2358:

> 2356: BSMAttributeEntries::start_extension(const BSMAttributeEntries& other, ClassLoaderData* loader_data, TRAPS) {
> 2357:   InsertionIterator iter = start_extension(other.number_of_entries(), other.array_length(),
> 2358:                                             loader_data, CHECK_(BSMAttributeEntries::InsertionIterator()));

Suggestion:

  InsertionIterator iter = start_extension(other.number_of_entries(), other.array_length(),
                                           loader_data, CHECK_(BSMAttributeEntries::InsertionIterator()));

-------------

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3277861284
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2386675664
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2386677067
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2386677720

From mhaessig at openjdk.org  Mon Sep 29 06:07:19 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 29 Sep 2025 06:07:19 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v9]
In-Reply-To: <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
Message-ID: <QFBdmbORb416h3q8peOIPnL59FwNHndMs0O7iFoEv4I=.44dd3129-ea21-428c-83ed-2a0ab4c61c52@github.com>

On Fri, 26 Sep 2025 20:07:36 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java
>   
>   Co-authored-by: Manuel H?ssig <manuel at haessig.org>

Marked as reviewed by mhaessig (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3278052544

From stefank at openjdk.org  Mon Sep 29 08:47:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 29 Sep 2025 08:47:21 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <pW9wtSPU8bQGqssN648DfvlwFj3yuTZhhYX8oJHHqDs=.05987cbc-8373-4284-bfef-f964999313d9@github.com>

On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed  change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion.
> 
> After this fix the VMDeath callback also can't generate any events. 
> The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion.
> 
> It might be still possible also to wait while all currently executing  events are completed. It is not required be specification, might add unneeded complexity. So  I want to apply this fix first and then to check if we still any problems.
> Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout.
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

Hi Leonid,

We currently have a shutdown issue where the GC is shut down before the last JVMTI events are sent from the same thread. The problem is that the JVMTI code allocates Java objects, which is problematic given that we've just shut down the GC threads.

Because of this extra allocation we have added a stop-gap solution that is not what we want long-term, but it fixes some reoccuring issue that was reported. The real solution involves switching the order between shutting down the GC threads and sending the last JVMTI event.

Take a look at before_exit in java.cpp:

  // Run before exit and then stop concurrent GC threads
  Universe::before_exit();

... // some unrelated code ...

  if (JvmtiExport::should_post_thread_life()) {
    JvmtiExport::post_thread_end(thread);
  }

  // Always call even when there are not JVMTI environments yet, since environments
  // may be attached late and JVMTI must track phases of VM execution
  JvmtiExport::post_vm_death();
  JvmtiAgentList::unload_agents();


The GC team thinks that the thread that shuts down the GC threads should not call code that allocates, so we would like to hoist the JVMTI code to before the code that stops the GC threads

... // some unrelated code ...

  if (JvmtiExport::should_post_thread_life()) {
    JvmtiExport::post_thread_end(thread);
  }

  // Always call even when there are not JVMTI environments yet, since environments
  // may be attached late and JVMTI must track phases of VM execution
  JvmtiExport::post_vm_death();
  JvmtiAgentList::unload_agents();

  // Run before exit and then stop concurrent GC threads
  Universe::before_exit();


There's a JBS entry created for the issue described above:
https://bugs.openjdk.org/browse/JDK-8367902

Given that you have looked into this VMDeath code and proposes a change to it, maybe you could help reasoning about if the above reordering would fit into what you proposes here in this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3345735398

From kevinw at openjdk.org  Mon Sep 29 10:18:29 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 29 Sep 2025 10:18:29 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v6]
In-Reply-To: <0_Btanzpu7MBuR8O5THxlgtBWB7ixaabMQHvbtFpJKQ=.9d4d65a6-037d-4f04-b9fe-802c21a70c16@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <0_Btanzpu7MBuR8O5THxlgtBWB7ixaabMQHvbtFpJKQ=.9d4d65a6-037d-4f04-b9fe-802c21a70c16@github.com>
Message-ID: <k5yim5KfB05Ipjj9ndZnNrs7Ajqb_-T2OaV3oUbCgjM=.d7749012-4741-496b-835a-58a9b26a11d7@github.com>

On Sun, 28 Sep 2025 21:19:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi 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 11 additional commits since the last revision:
> 
>  - new check
>  - Merge branch 'master' into JDK-8367609
>  - nn
>  - comment and rename
>  - invert
>  - review
>  - simplify
>  - fix
>  - simple fix
>  - fix
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/81ac630a...70eaa2bb

OK glad it works. 8-)

Maybe a comment above line 423 so say something like:
// Account for the PH being at some vaddr offset from mapping in core file.

We could have left the ROUNDUP on line 427 to the comparison on line 431 to make it more like the original.  I think either way is good.

Good for me, let's check Chris who looked at it also agrees.

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27274#pullrequestreview-3278976960

From myankelevich at openjdk.org  Mon Sep 29 10:28:19 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 29 Sep 2025 10:28:19 GMT
Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v3]
In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
Message-ID: <iWr9NfPTK1SgsC0M8bFlnv0tRvIeCPI4P_X9J_ddrHo=.685f585d-dcad-4c49-b3e8-5884faeeb05f@github.com>

> Tests changed in this PR: 
> 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java
> 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java
> 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java
> 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java
> 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
> 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java
> 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java
> 12. test/jdk/sun/security/rsa/InvalidBitString.java
> 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java
> 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java
> 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java
> 
> PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326)

Mikhail Yankelevich has updated the pull request incrementally with 364 additional commits since the last revision:

 - removed pemrecord usage
 - 8365190: Remove LockingMode related code from share
   
   Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo
 - 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp
   
   Reviewed-by: aboldtch, tschatzl, jwaters
 - 8360219: [AIX] assert(locals_base >= l2) failed: bad placement
   
   Reviewed-by: dlong, mdoerr
 - 8366864: Sort os/linux includes
   
   Reviewed-by: ayang, dholmes
 - 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages
   
   Reviewed-by: ayang, shade, stefank, tschatzl
 - 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR)
   
   Reviewed-by: vromero
 - 8365776: Convert JShell tests to use JUnit instead of TestNG
   
   Reviewed-by: vromero
 - 8354871: Replace stack map frame type magics with constants
   
   Reviewed-by: liach
 - 8361533: Apply java.io.Serial annotations in java.logging
   
   Reviewed-by: rriggs
 - ... and 354 more: https://git.openjdk.org/jdk/compare/d44cb277...e0be5eaa

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27194/files
  - new: https://git.openjdk.org/jdk/pull/27194/files/d44cb277..e0be5eaa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=01-02

  Stats: 53711 lines in 1891 files changed: 31453 ins; 14034 del; 8224 mod
  Patch: https://git.openjdk.org/jdk/pull/27194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194

PR: https://git.openjdk.org/jdk/pull/27194

From fandreuzzi at openjdk.org  Mon Sep 29 10:50:36 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 29 Sep 2025 10:50:36 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v7]
In-Reply-To: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
Message-ID: <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>

> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
> 
> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
> 
> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
> 
> I added some files to the ticket for context.
> 
> Passes `tier1` and `tier2`.

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  cc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27274/files
  - new: https://git.openjdk.org/jdk/pull/27274/files/70eaa2bb..fe9adaff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27274&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27274&range=05-06

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27274.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27274/head:pull/27274

PR: https://git.openjdk.org/jdk/pull/27274

From kevinw at openjdk.org  Mon Sep 29 11:21:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 29 Sep 2025 11:21:08 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v7]
In-Reply-To: <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
Message-ID: <41wMm5U4DZVtrNILrgCVJYA-VECHi1i6p4jNJBM9Cgk=.277d1510-ee8d-4c53-b3ae-09465d0904c2@github.com>

On Mon, 29 Sep 2025 10:50:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cc

Marked as reviewed by kevinw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27274#pullrequestreview-3279190116

From kevinw at openjdk.org  Mon Sep 29 12:08:14 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 29 Sep 2025 12:08:14 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <aFPbqgoyuZLZ5uGG1vSnmKd3XVEwUwkEq2B-oIgKrx0=.55a507d5-aa05-4d20-a35d-4b5f985a0b2b@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

src/hotspot/share/include/jmm.h line 85:

> 83:   JMM_GC_COUNT                       = 10,   /* Total number of collections */
> 84:   JMM_GC_CPU_TIME                    = 11,   /* Total accumulated GC CPU time */
> 85:   JMM_JVM_UPTIME_MS                  = 12,   /* The JVM uptime in milliseconds */

It looks a bit odd to me to change the existing define of UPTIME here.  
OK it is not a public interface used between different versions, and people should not be mixing up jmm.h and management implementations...  But usually we would just add the new definition? (items below are not strictly grouped by name)  Maybe this is just a nit, and only makes cross-version comparisons easier.

Looks good overall.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2387698942

From cjplummer at openjdk.org  Mon Sep 29 17:49:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 29 Sep 2025 17:49:17 GMT
Subject: RFR: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing [v2]
In-Reply-To: <zX-c8zkKFhNyOgDEvolme0OApFyIW6HjQEkAqe5TRog=.602a87ab-d449-4d6b-a848-76123f87581c@github.com>
References: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
 <zX-c8zkKFhNyOgDEvolme0OApFyIW6HjQEkAqe5TRog=.602a87ab-d449-4d6b-a848-76123f87581c@github.com>
Message-ID: <n9s4cRMui_HFyxHzgC333iLT5smJtMOmZlNnMORk31I=.c3e5bfc4-0b1d-4c49-a875-babb4b27d32c@github.com>

On Wed, 24 Sep 2025 23:32:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fixed an issue with a race with two events coming in close to the same time, the first of which does not suspend any debuggee threads. More details in the first comment.
>> 
>> Tested by running all vmTestbase/nsk/jdi tests 25x times on all platforms both with and w/o virtual threads. Also ran all tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unneeded synchronized

Thank you for the reviews Alex and Serguei!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27370#issuecomment-3348237699

From cjplummer at openjdk.org  Mon Sep 29 17:49:18 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 29 Sep 2025 17:49:18 GMT
Subject: Integrated: 8367318: Test
 vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java
 timed out after passing
In-Reply-To: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
References: <cYnECTQiWhfI586b32ozDcxO29xpFwut5b-y9QLEnvk=.ad2acc11-9d76-4e58-bd9d-c37ab582b3f4@github.com>
Message-ID: <8zG0Xue10ludjdJ4LZwq0w8jPDotPnuCOfvcbwPTr5s=.0a5174b5-aaf1-49ed-8c8b-66b2bd0a1283@github.com>

On Thu, 18 Sep 2025 18:01:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fixed an issue with a race with two events coming in close to the same time, the first of which does not suspend any debuggee threads. More details in the first comment.
> 
> Tested by running all vmTestbase/nsk/jdi tests 25x times on all platforms both with and w/o virtual threads. Also ran all tier5 svc tests.

This pull request has now been integrated.

Changeset: 3d97e17a
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d97e17a31c267161c2be87b551cdb118062ff57
Stats:     21 lines in 2 files changed: 4 ins; 6 del; 11 mod

8367318: Test vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java timed out after passing

Reviewed-by: amenkov, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/27370

From jsjolen at openjdk.org  Mon Sep 29 17:57:57 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 29 Sep 2025 17:57:57 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v9]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <HREC_71BpJ2ktDEyLH4s-DbNywK_9yGF0LOazWzmNGw=.84cf0d08-e318-4cd0-8425-486819141f81@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Apply suggestions from code review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Wrap size calc into static method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/f96a16e5..5a42b0df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=07-08

  Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

PR: https://git.openjdk.org/jdk/pull/27198

From jsjolen at openjdk.org  Mon Sep 29 17:58:01 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 29 Sep 2025 17:58:01 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com>
Message-ID: <AIkJgg5hTRNnDhcRj_T8Y6uf96lDs0OHY8e1k8oJgTI=.37afb0a8-f8fe-4b18-a2e0-908f7b57d5cc@github.com>

On Thu, 18 Sep 2025 21:27:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix rename
>
> src/hotspot/share/oops/constantPool.inline.hpp line 93:
> 
>> 91: inline BSMAttributeEntry* BSMAttributeEntries::InsertionIterator::reserve_new_entry(u2 bsmi, u2 argc) {
>> 92:   if (_cur_offset + 1 > insert_into->offsets()->length() ||
>> 93:       _cur_array + 1 + 1 + argc > insert_into->bootstrap_methods()->length()) {
> 
> The `+ 1 + 1 + argc` looks a little magical - can we factor it out and explain it e.g.
> 
> int next_array = _cur_array + 1 /* ??? */ + 1 /* ??? */ + argc;
> ...
> _curr_array = next_array;
> ...

I wrapped the size calculation into `BSMAE::u2s_needed`  and annotated the magic numbers there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2388764436

From lmesnik at openjdk.org  Mon Sep 29 18:09:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 29 Sep 2025 18:09:43 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <liwWOmmiL1d5oMhGuj1ClzCuKEBwiyjxYIsVOP8jd5s=.9b73a729-6e73-4ba5-a3e5-eb83963dd133@github.com>

On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed  change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion.
> 
> After this fix the VMDeath callback also can't generate any events. 
> The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion.
> 
> It might be still possible also to wait while all currently executing  events are completed. It is not required be specification, might add unneeded complexity. So  I want to apply this fix first and then to check if we still any problems.
> Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout.
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

The VM Death call back is still valid point to call any java code. So the GC should be active at this point. I quickly check that 'Universe::before_exit()' doesn't post any jvmti events, so it makes sense to call it after vm death.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3348335060

From cjplummer at openjdk.org  Mon Sep 29 20:52:37 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 29 Sep 2025 20:52:37 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v7]
In-Reply-To: <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
Message-ID: <ehcFrMx1yM2xiVHt1dunRnDBIiR6MoAwOIfTB7n3gPY=.bb4fcd1f-c501-47c3-a56f-3125a7278b6a@github.com>

On Mon, 29 Sep 2025 10:50:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cc

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 428:

> 426:             lib_memsz += target_vaddr - existing_map->vaddr;
> 427:         }
> 428: 

I think this change looks good, but just want to make sure I'm understanding it properly. Kevin commented the following:


hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5)

          print_error("address conflict @ 0x%lx (existing map size = %ld, size = %ld, flags = %d)\n",
                        target_vaddr, existing_map->memsz, lib_php->p_memsz, lib_php->p_flags);

core has no mapping at exactly 0x7fa9ff0e4440 but has:

  Start                 End               Page Offset
  0x00007fa9ff0db000  0x00007fa9ff0e4000  0x0000000000000000 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so  (0x9000 size) 0x841c rounded up
  0x00007fa9ff0e4000  0x00007fa9ff0fd000  0x0000000000000008 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so (0x19000 size) the existing map size from the error


So the problem here is that we were expecting 0x00007fa9ff0e4000 but got 0x7fa9ff0e4440. Basically target_vaddr is at an unexpected offset from existing_map->vaddr. The fix is to ad this offset to lib_memsz so the error is no longer triggered. Do we understand why this offset is happening?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2389240885

From duke at openjdk.org  Tue Sep 30 04:38:48 2025
From: duke at openjdk.org (Bernd)
Date: Tue, 30 Sep 2025 04:38:48 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Thanks, it?s a useful function. (I would not have expected it in the memory bean but in the go bean, but I guess both is fine.) Some more comments inline

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 273:

> 271:      * Returns the CPU time used by all garbage collection threads.
> 272:      *
> 273:      * <p> This include time since genesis, so the value can be

The ?so the? is not too obvious to me. Maybe simplify it a bit ?This includes time since genesis and counts activities even before the first collection cycle.??

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 279:

> 277:      * deduplication thread (if enabled). This method returns
> 278:      * {@code -1} if the platform does not support this operation
> 279:      * or if called during shutdown.

Can we explicitly state here that this is concurrent time as well as worker time spent during pauses but not accumulated pause times?

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 282:

> 280:      *
> 281:      * @return the total CPU time for all garbage collection
> 282:      * threads in nanoseconds.

Not sure did I miss the discussion, other methods like getTotalCompilationTime() return millis, is it ok or required to use new units here?

test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java line 73:

> 71:                 while (true) {
> 72:                     long gcCpuTimeFromThread = mxMemoryBean.getGcCpuTime();
> 73:                     if (gcCpuTimeFromThread < -1) {

None of the tests actually test if it is ever != -1 or if it is monotonically increasing or under which conditions (go? Platform? Build flags?) it is unsupported?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3282521865
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389806062
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389808338
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389815933
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389822026

From dholmes at openjdk.org  Tue Sep 30 06:30:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Sep 2025 06:30:48 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com>

On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> After this fix the VMDeath callback also can't generate any events.

I think this needs a CSR request and likely a release note. Though if you plan to later wait for all event processing to complete, is it even necessary to make the current change? The spec is very imprecise when it comes to when exactly no further events will be processed, but it seems reasonable to expect that the callback for VM_DEATH is the last thing that should generate events. Though unless event processing is fully synchronized with locks (which I'm pretty sure it isn't) then you have races no matter what you do. I am concerned that, given you cannot completely prevent events from being generated "after" VM_DEATH, the change may "break" more code than it "fixes". ??

src/hotspot/share/prims/jvmtiEventController.cpp line 1060:

> 1058: void
> 1059: JvmtiEventControllerPrivate::vm_death() {
> 1060:   _execution_finished = true;

Unless there is some lock guarding this that I cannot see in this diff, if you want to ensure this will be seen as soon as possible then you need a `store_fence` (and the variable should be `volatile` - and will be a candidate for `Atomic<T>`). You are still racing with others threads but this would at least attempt to minimise the window.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27504#pullrequestreview-3282743437
PR Review Comment: https://git.openjdk.org/jdk/pull/27504#discussion_r2389970167

From dholmes at openjdk.org  Tue Sep 30 07:09:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Sep 2025 07:09:59 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v9]
In-Reply-To: <HREC_71BpJ2ktDEyLH4s-DbNywK_9yGF0LOazWzmNGw=.84cf0d08-e318-4cd0-8425-486819141f81@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <HREC_71BpJ2ktDEyLH4s-DbNywK_9yGF0LOazWzmNGw=.84cf0d08-e318-4cd0-8425-486819141f81@github.com>
Message-ID: <2Sj-S9Au_zYHUwDITCnAkoUBPAGpG-bOLJMrnFbBNDY=.95369cfe-a4f0-4727-a026-5203f26414ae@github.com>

On Mon, 29 Sep 2025 17:57:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Wrap size calc into static method

src/hotspot/share/oops/constantPool.hpp line 127:

> 125: 
> 126:   // How many u2s are required to store a BSM entry with argc arguments?
> 127:   static size_t u2s_required (u2 argc) {

Suggestion:

  static int u2s_required (u2 argc) {

If you are going to cast the result to an int, it may as well be an int anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2390090412

From duke at openjdk.org  Tue Sep 30 09:02:39 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:02:39 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
Message-ID: <-vYR7lb41d_yoyG72ApZMuHpTNY8nTDW33m_0O04NVg=.8ee6f963-446a-4116-9f80-4c1fe37eb3d3@github.com>

On Tue, 30 Sep 2025 04:29:40 GMT, Bernd <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 282:
> 
>> 280:      *
>> 281:      * @return the total CPU time for all garbage collection
>> 282:      * threads in nanoseconds.
> 
> Not sure did I miss the discussion, other methods like getTotalCompilationTime() return millis, is it ok or required to use new units here?

It is indeed unfortunate that methods mix units but we are complementing, `OperatingSystemMXBean.getProcessCpuTime()` which returns nanoseconds.

> test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java line 73:
> 
>> 71:                 while (true) {
>> 72:                     long gcCpuTimeFromThread = mxMemoryBean.getGcCpuTime();
>> 73:                     if (gcCpuTimeFromThread < -1) {
> 
> None of the tests actually test if it is ever != -1 or if it is monotonically increasing or under which conditions (go? Platform? Build flags?) it is unsupported?

The reason why there is no test for that is because `-1` is a valid return value. If this test is run on a system that does not support CPU time from os or if it queried during shutdown when we are terminating threads we opt to return `-1` for safety reasons. We cannot assume that OpenJDK is never run on a platform that does not support certain optional `os` implementations.

The goal with this test is to verify the shutdown protection and the API. Additionally, since this API is piggybacking on other methods (effectively in `os`) that are actually responsible for the CPU time functionality, I believe they would be responsible implement tests for what you suggest.

FWIW; I had a quick look and the tests that you are expecting might already be found in e.g. `test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadMonitor.java`, `vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001/TestDescription.java`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390416360
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390406537

From duke at openjdk.org  Tue Sep 30 09:11:49 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:11:49 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
Message-ID: <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>

On Tue, 30 Sep 2025 04:21:44 GMT, Bernd <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 273:
> 
>> 271:      * Returns the CPU time used by all garbage collection threads.
>> 272:      *
>> 273:      * <p> This include time since genesis, so the value can be
> 
> The ?so the? is not too obvious to me. Maybe simplify it a bit ?This includes time since genesis and counts activities even before the first collection cycle.??

Thanks @ecki for pointing that out :) I make a simplification whenever the CSR discussion (https://bugs.openjdk.org/browse/JDK-8368529) have reached a consensus where this method should live.

> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 279:
> 
>> 277:      * deduplication thread (if enabled). This method returns
>> 278:      * {@code -1} if the platform does not support this operation
>> 279:      * or if called during shutdown.
> 
> Can we explicitly state here that this is concurrent time as well as worker time spent during pauses but not accumulated pause times?

Just want to ensure that I read this correct, please correct any mistake below:

* concurrent time = `CPU time`
* accumulate times = `wall-clock time`

Is your suggestion that we should clarify that the method may only account for `CPU time` and not `wall-clock time` during pauses?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390466153
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390453810

From duke at openjdk.org  Tue Sep 30 09:18:12 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:18:12 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <leYHhsAOI1HJEGUhPdBCK3ww2ficj5fJoUFTxAa8Dnk=.3dfdb3ef-1508-46c0-8fba-1dae6bdb70e1@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Thanks @kevinjwalls for your review. I will update the order in `jmm.h` whenever we have reached a consensus in the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3350875133

From duke at openjdk.org  Tue Sep 30 09:22:18 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:22:18 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
Message-ID: <FVVak25Et_CRvOJRToV6PJf5l-mrjEYWZo0KVm9H3hc=.c908c72d-e74d-41c4-bf87-4ef1943eaba4@github.com>

On Tue, 30 Sep 2025 04:35:46 GMT, Bernd <duke at openjdk.org> wrote:

> Thanks, it?s a useful function

@ecki That's great to hear ?! Thanks for taking your time to go through this and provide feedback/comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3350891366

From duke at openjdk.org  Tue Sep 30 09:22:20 2025
From: duke at openjdk.org (Bernd)
Date: Tue, 30 Sep 2025 09:22:20 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
Message-ID: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>

On Tue, 30 Sep 2025 09:06:48 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 279:
>> 
>>> 277:      * deduplication thread (if enabled). This method returns
>>> 278:      * {@code -1} if the platform does not support this operation
>>> 279:      * or if called during shutdown.
>> 
>> Can we explicitly state here that this is concurrent time as well as worker time spent during pauses but not accumulated pause times?
>
> Just want to ensure that I read this correct, please correct any mistake below:
> 
> * concurrent time = `CPU time`
> * accumulate times = `wall-clock time`
> 
> Is your suggestion that we should clarify that the method may only account for `CPU time` and not `wall-clock time` during pauses?

It?s mostly about making clear it?s Not a measurement for pause time (no matter if wall clock or per thread), dont know how to best Formulate it. I think it?s needed sind typically pause times have been associated with GRC thread Timings. Maybe something like ?the accounted CPU time can be spent concurrently with application threads or during pauses? or something Like that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390505263

From duke at openjdk.org  Tue Sep 30 09:28:25 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 09:28:25 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
 <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
Message-ID: <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>

On Tue, 30 Sep 2025 09:19:28 GMT, Bernd <duke at openjdk.org> wrote:

>> Just want to ensure that I read this correct, please correct any mistake below:
>> 
>> * concurrent time = `CPU time`
>> * accumulate times = `wall-clock time`
>> 
>> Is your suggestion that we should clarify that the method may only account for `CPU time` and not `wall-clock time` during pauses?
>
> It?s mostly about making clear it?s Not a measurement for pause time (no matter if wall clock or per thread), dont know how to best Formulate it. I think it?s needed sind typically pause times have been associated with GRC thread Timings. Maybe something like ?the accounted CPU time can be spent concurrently with application threads or during pauses? or something Like that?

In the CSR discussion I proposed changing the method name to `getTotalGcCpuTime()` as @kevinjwalls raised concerns about conflating it with per generation CPU timings. Would the renaming to `getTotalGcCpuTime()` also solve your concern here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390533951

From duke at openjdk.org  Tue Sep 30 09:41:26 2025
From: duke at openjdk.org (Bernd)
Date: Tue, 30 Sep 2025 09:41:26 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <-vYR7lb41d_yoyG72ApZMuHpTNY8nTDW33m_0O04NVg=.8ee6f963-446a-4116-9f80-4c1fe37eb3d3@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <-vYR7lb41d_yoyG72ApZMuHpTNY8nTDW33m_0O04NVg=.8ee6f963-446a-4116-9f80-4c1fe37eb3d3@github.com>
Message-ID: <c6PwyV6Nu91uRUPEI5Gk3jnfI5IlhpLtp3OO0rk3Lc8=.56ff6be9-5eba-4b32-afed-6d3a19a6a6b9@github.com>

On Tue, 30 Sep 2025 08:58:54 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 282:
>> 
>>> 280:      *
>>> 281:      * @return the total CPU time for all garbage collection
>>> 282:      * threads in nanoseconds.
>> 
>> Not sure did I miss the discussion, other methods like getTotalCompilationTime() return millis, is it ok or required to use new units here?
>
> It is indeed unfortunate that methods mix units but we are complementing, `OperatingSystemMXBean.getProcessCpuTime()` which returns nanoseconds.

It?s in Both names - especially with the Description - understandable what it means, I was just afraid that people could confuse concepts. Maybe it doesn?t really matter. I think in the gc specific ones the colateral doc was a bit more specific about concurrent times and pauses, in the past.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390586886

From kevinw at openjdk.org  Tue Sep 30 10:22:46 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 30 Sep 2025 10:22:46 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v7]
In-Reply-To: <ehcFrMx1yM2xiVHt1dunRnDBIiR6MoAwOIfTB7n3gPY=.bb4fcd1f-c501-47c3-a56f-3125a7278b6a@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
 <ehcFrMx1yM2xiVHt1dunRnDBIiR6MoAwOIfTB7n3gPY=.bb4fcd1f-c501-47c3-a56f-3125a7278b6a@github.com>
Message-ID: <rDv_SECSJJdKdeh4K987tsU90IKR9yh_fymfdDWhwt8=.0e2494dd-54f4-4cfd-bfae-8093d0f87016@github.com>

On Mon, 29 Sep 2025 20:49:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>  Do we understand why this offset is happening?

It looks like the binary is just built differently, clang or the linker or some combination arranges things differently to what we have seen from gcc.

Maybe it's enough to say there doesn't have to be a 1:1 mapping from program headers to segments in the process.
We can have a core file segment that contains more than one program header from the library (that 0x19000 size segment at the libjimage base address).


So, new question: 

we must have been through this loop already, in the libjimage example with the first LOAD PH of size 0x000000000000841c at the library base address.

Did that pass the same test?
No it can't, the mapping is 0x19000 and size 0x841c does not round up to that.
I think we must ignore the first LOAD PH from the clang build as we check:

	408       } else if (lib_php->p_flags != existing_map->flags) {
	
..and the first LOAD PH from https://bugs.openjdk.org/secure/attachment/116209/3libjimage_all.txt
..is a Read only, not execute.

This should be OK in this case:

https://bugs.openjdk.org/secure/attachment/116199/3core_all.txt
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000141000 0x00007fa9ff0e4000 0x0000000000000000
                 0x0000000000019000 0x0000000000019000  R E    0x1000				
				 
Filesize and memsiz both 0x019000 must mean the core contains everything, we don't need either of these from the library.
But there is no harm in continuing past the problematic check and populating existing_map from the library.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2390746069

From alanb at openjdk.org  Tue Sep 30 10:45:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Sep 2025 10:45:15 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
Message-ID: <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>

On Mon, 29 Sep 2025 01:33:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request

The CSR is probably a bit premature as this one is going to require seeing if the existing MXBeans are the best place for this (at least some of the original modelling assumed STW collectors) or whether a new management interface is needed.

It will need think about whether should be a standard or JDK-specific API. Right now, the draft API spec makes it sounds very HotSpot VM specific.

If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3351299156

From kevinw at openjdk.org  Tue Sep 30 10:48:00 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 30 Sep 2025 10:48:00 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
 <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
 <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>
Message-ID: <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com>

On Tue, 30 Sep 2025 09:25:24 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> It?s mostly about making clear it?s Not a measurement for pause time (no matter if wall clock or per thread), dont know how to best Formulate it. I think it?s needed sind typically pause times have been associated with GRC thread Timings. Maybe something like ?the accounted CPU time can be spent concurrently with application threads or during pauses? or something Like that?
>
> In the CSR discussion I proposed changing the method name to `getTotalGcCpuTime()` as @kevinjwalls raised concerns about conflating it with per generation CPU timings. Would the renaming to `getTotalGcCpuTime()` also solve your concern here?

Also, genesis (Universe::genesis()?), is a VM detail that may be unclear.  Do we mean:
"
Returns the CPU time used by all garbage collection threads.

This includes time for all driver threads, workers, VM operations
on the VM thread, and the string deduplication thread (if enabled). 
Therefore the value can be non-zero even if no garbage collection cycles have occurred. 

This method returns {@code -1} if the platform does not support this operation, or if called during shutdown.
"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390853215

From duke at openjdk.org  Tue Sep 30 11:25:53 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 11:25:53 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
Message-ID: <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>

On Tue, 30 Sep 2025 10:41:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request
>
>> I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request
> 
> The CSR is probably a bit premature as this one is going to require seeing if the existing MXBeans are the best place for this (at least some of the original modelling assumed STW collectors) or whether a new management interface is needed.
> 
> It will need think about whether should be a standard or JDK-specific API. Right now, the draft API spec makes it sounds very HotSpot VM specific.
> 
> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.

@AlanBateman

> The CSR is probably a bit premature ...

Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?

> Right now, the draft API spec makes it sounds very HotSpot VM specific.

Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?

> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.

Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3351513274

From duke at openjdk.org  Tue Sep 30 11:44:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 30 Sep 2025 11:44:43 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
 <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
 <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>
 <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com>
Message-ID: <wGT65p7pZ1oeQUuLqVWguR0LRh6aSOaz-vQFAmDRyCc=.0b190f95-b0b3-4c59-8351-d1e1da97a6a5@github.com>

On Tue, 30 Sep 2025 10:45:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> In the CSR discussion I proposed changing the method name to `getTotalGcCpuTime()` as @kevinjwalls raised concerns about conflating it with per generation CPU timings. Would the renaming to `getTotalGcCpuTime()` also solve your concern here?
>
> Also, genesis (Universe::genesis()?), is a VM detail that may be unclear.  Do we mean:
> "
> Returns the CPU time used by all garbage collection threads.
> 
> This includes time for all driver threads, workers, VM operations
> on the VM thread, and the string deduplication thread (if enabled). 
> Therefore the value can be non-zero even if no garbage collection cycles have occurred. 
> 
> This method returns {@code -1} if the platform does not support this operation, or if called during shutdown.
> "

I meant genesis in the literal sense i.e. since thread creation not relating to `Universe::genesis`. It may be non-zero since each there may do some initialization work and thus CPU time would be non-zero. However given @AlanBateman comment about being HotSpot VM specific should we avoid talking about these specific details here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2391079350

From kevinw at openjdk.org  Tue Sep 30 11:53:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 30 Sep 2025 11:53:23 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <wGT65p7pZ1oeQUuLqVWguR0LRh6aSOaz-vQFAmDRyCc=.0b190f95-b0b3-4c59-8351-d1e1da97a6a5@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <n_UVsrieTjKVFRxCwE9wCO12xMwT1CvFJpBKy7QUcAM=.ebca2f32-9ca7-439a-9daf-d917677a63a1@github.com>
 <Yt3S23NfjAy_pLSJ6cU7syKxk2dogI5ve0qk7nIGb6k=.09ce07de-15c4-460b-9357-a0c856595c28@github.com>
 <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com>
 <JuFxqlow04l6iEawuk3retkexmbWZe0TeZABxKJwdY8=.9ff397d7-d7e6-4231-bc49-00e262843662@github.com>
 <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com>
 <wGT65p7pZ1oeQUuLqVWguR0LRh6aSOaz-vQFAmDRyCc=.0b190f95-b0b3-4c59-8351-d1e1da97a6a5@github.com>
Message-ID: <A1NxElV-BuPWjHZJR50mklz-6mezEuEVfGdXjAH9oR4=.d10d7c85-593a-4b81-ad74-5dec10332666@github.com>

On Tue, 30 Sep 2025 11:41:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Also, genesis (Universe::genesis()?), is a VM detail that may be unclear.  Do we mean:
>> "
>> Returns the CPU time used by all garbage collection threads.
>> 
>> This includes time for all driver threads, workers, VM operations
>> on the VM thread, and the string deduplication thread (if enabled). 
>> Therefore the value can be non-zero even if no garbage collection cycles have occurred. 
>> 
>> This method returns {@code -1} if the platform does not support this operation, or if called during shutdown.
>> "
>
> I meant genesis in the literal sense i.e. since thread creation not relating to `Universe::genesis`. It may be non-zero since each there may do some initialization work and thus CPU time would be non-zero. However given @AlanBateman comment about being HotSpot VM specific should we avoid talking about these specific details here?

"CPU time used by all garbage collection threads"  or even "Accumulated CPU time..." would seem clear that we mean these threads, in this process.  We can leave genesis out of it, whether it meant start of process or dawn of time. 8-)

Yes, might be better as just, "This may include some startup work and overhead, therefore the value can be non-zero even...".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2391101498

From lmesnik at openjdk.org  Tue Sep 30 15:18:57 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 30 Sep 2025 15:18:57 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
 <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com>
Message-ID: <e14_tchCZQbLjgBAyGAwjEiyJ1FZ0UMddNjrAqRFy6w=.624bb957-a3c4-45e6-b8c4-027f4f160b0a@github.com>

On Tue, 30 Sep 2025 06:11:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
>> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
>> 
>> However, current implementation changes state and only after this start disabling events.  
>> 
>> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
>> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
>> 
>> The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed  change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion.
>> 
>> After this fix the VMDeath callback also can't generate any events. 
>> The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion.
>> 
>> It might be still possible also to wait while all currently executing  events are completed. It is not required be specification, might add unneeded complexity. So  I want to apply this fix first and then to check if we still any problems.
>> Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout.
>> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.
>
> src/hotspot/share/prims/jvmtiEventController.cpp line 1060:
> 
>> 1058: void
>> 1059: JvmtiEventControllerPrivate::vm_death() {
>> 1060:   _execution_finished = true;
> 
> Unless there is some lock guarding this that I cannot see in this diff, if you want to ensure this will be seen as soon as possible then you need a `store_fence` (and the variable should be `volatile` - and will be a candidate for `Atomic<T>`). You are still racing with others threads but this would at least attempt to minimise the window.

I forgot to put this in description and  mentioned the first comment. 
The access to variable is protected with JvmtiThreadState_lock. 
Am I understand correctly, that it is enough to correctly synchronize it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27504#discussion_r2391984202

From lmesnik at openjdk.org  Tue Sep 30 15:41:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 30 Sep 2025 15:41:43 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
 <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com>
Message-ID: <KI7OHrB3KP02r2LDX32_Xeinnn9WZBsJhsUvbREvmiI=.273ee2f6-0dab-4cc7-a4c8-8e3df0c46e1c@github.com>

On Tue, 30 Sep 2025 06:28:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > After this fix the VMDeath callback also can't generate any events.
> 
> I think this needs a CSR request and likely a release note. Though if you plan to later wait for all event processing to complete, is it even necessary to make the current change? The spec is very imprecise when it comes to when exactly no further events will be processed, but it seems reasonable to expect that the callback for VM_DEATH is the last thing that should generate events. Though unless event processing is fully synchronized with locks (which I'm pretty sure it isn't) then you have races no matter what you do. I am concerned that, given you cannot completely prevent events from being generated "after" VM_DEATH, the change may "break" more code than it "fixes". ??

This change completely prevents generation of events after VM Death is posted. While the callback execution is might be in the progress. I plan to fix this later. The main problem would be dealing with long-processing events in daemon threads. 

Right now I am not sure if CSR is needed. The new  behaviour doesn't require specification changes. I want to implement this fix separately to ensure that it doesn't break anything.  Then I plan to add synchronization separately. This fix also doesn't change specification, because spec is very 'imprecise' as you mentioned.  
It might be makes sense to amend specification saying explicitly that VM Death is the last event generated in the VM. But is it  needed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3352791338