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