From sspitsyn at openjdk.org  Fri Aug  1 09:44:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Aug 2025 09:44:56 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
Message-ID: <7LrTOiuQ3p-wZPtvdr-WkDPFzEawcmEeXzEtaIaJTrk=.5e74eda0-5414-4b13-935e-75f6f2a3f486@github.com>

On Thu, 31 Jul 2025 03:45:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`.
>> 
>> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`.
>> 
>> There are a couple of concerns with this fix which would be nice to sort out with reviewers:
>> 1.  The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue)
>> 2.  The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess`
>> 
>> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`.
>> 
>> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it.
>> 
>> Testing:
>>  - Mach5 tiers 1-6 are passed
>>  - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest`
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo: in latest update

Thank you for review and suggestions, Alan and Patricio!

David, do you have any concerns or suggestions? Should I wait for your approval?

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

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3143917402
PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3143921149

From sspitsyn at openjdk.org  Fri Aug  1 09:44:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Aug 2025 09:44:57 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
Message-ID: <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>

On Thu, 31 Jul 2025 15:49:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo: in latest update
>
> src/hotspot/share/prims/jvm.cpp line 2899:
> 
>> 2897:       // An asynchronous exception could have been thrown on
>> 2898:       // us while we were sleeping. We do not overwrite those.
>> 2899:       if (!HAS_PENDING_EXCEPTION) {
> 
> Maybe not for this bug but we have this `HAS_PENDING_EXCEPTION` check here and further up but I don't see how we can have a pending exception when calling this method. Based on the comment here seems we just wanted to check the async ones as added now.

Should we always have `HAS_PENDING_EXCEPTION == true` if async exception was installed?
If so, then this newly added check is not really needed:

           if (!thread->has_async_exception_condition()) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2247472186

From alanb at openjdk.org  Fri Aug  1 10:58:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Aug 2025 10:58:55 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: <Ufhw-ozaC9oy_gcm5VhQODSkeRRFJM-vFhkOL_dB-wI=.8ecf2dce-84e6-48f0-9985-4b8f534f9109@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

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26548#pullrequestreview-3078761756

From alanb at openjdk.org  Fri Aug  1 10:58:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Aug 2025 10:58:56 GMT
Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v3]
In-Reply-To: <9SkMM4987vYvh22RZYgvyLyE4V472fhsjN1HIOccMUM=.23262968-ee25-483a-86ec-0009bf25c5fd@github.com>
References: <ZItLUA6qC4OkLvIijLnEFv9OpBDuuR4iOvudXerRcVo=.9e48a280-8247-4d35-973e-446fa6a7e668@github.com>
 <Wl7oJEfbnsO3_W8nBWMBgf6FQO6oaOXQbekmaAY4XWY=.d6a7b6fa-d042-41e4-b713-f87791a7be4d@github.com>
 <lklLUphcCksYL1KrRyk4oQfb-cmgeW_YFFEtzySZf0k=.44227da8-69f0-4d58-93aa-f7226a6651f0@github.com>
 <9SkMM4987vYvh22RZYgvyLyE4V472fhsjN1HIOccMUM=.23262968-ee25-483a-86ec-0009bf25c5fd@github.com>
Message-ID: <BmLchQfYxbLIhcc5z6W53GrZ0FufB_9Fo22inwILu6U=.396a8b65-8b7a-424c-ba1d-3b804f781b4e@github.com>

On Thu, 31 Jul 2025 16:47:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> . _Should_ I make this a junit test, is that required, desirable, unnecessary...

What you have is okay, I was just pointing out that you could use it here to create a more modern test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26548#discussion_r2247683986

From kevinw at openjdk.org  Fri Aug  1 11:09:54 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Aug 2025 11:09:54 GMT
Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v3]
In-Reply-To: <BmLchQfYxbLIhcc5z6W53GrZ0FufB_9Fo22inwILu6U=.396a8b65-8b7a-424c-ba1d-3b804f781b4e@github.com>
References: <ZItLUA6qC4OkLvIijLnEFv9OpBDuuR4iOvudXerRcVo=.9e48a280-8247-4d35-973e-446fa6a7e668@github.com>
 <Wl7oJEfbnsO3_W8nBWMBgf6FQO6oaOXQbekmaAY4XWY=.d6a7b6fa-d042-41e4-b713-f87791a7be4d@github.com>
 <lklLUphcCksYL1KrRyk4oQfb-cmgeW_YFFEtzySZf0k=.44227da8-69f0-4d58-93aa-f7226a6651f0@github.com>
 <9SkMM4987vYvh22RZYgvyLyE4V472fhsjN1HIOccMUM=.23262968-ee25-483a-86ec-0009bf25c5fd@github.com>
 <BmLchQfYxbLIhcc5z6W53GrZ0FufB_9Fo22inwILu6U=.396a8b65-8b7a-424c-ba1d-3b804f781b4e@github.com>
Message-ID: <mxHpy0_4-bKecBnY6yaph7pqKOJgnZlWwGiC91KZ6C4=.ba5757f4-706d-4f54-b6cc-d0da255d275f@github.com>

On Fri, 1 Aug 2025 10:54:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks for the CSR update.
>> 
>> I was just following the norm for the area with the test.
>> _Should_ I make this a junit test, is that required, desirable, unnecessary...
>
>> . _Should_ I make this a junit test, is that required, desirable, unnecessary...
> 
> What you have is okay, I was just pointing out that you could use it here to create a more modern test.

Great, yes I'm just fishing for other rules.   Happy to leave this test in the same form as its companion tests at the moment.

Many thanks for quick review here and on the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26548#discussion_r2247703714

From pchilanomate at openjdk.org  Fri Aug  1 14:09:04 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Aug 2025 14:09:04 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
 <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>
Message-ID: <Ci_ghq96Gr9rvBiRyA03gDvm958HGPANPME27TOIj6I=.a4097777-0ae1-4fe8-95c3-21dc6815ec68@github.com>

On Fri, 1 Aug 2025 09:40:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 2899:
>> 
>>> 2897:       // An asynchronous exception could have been thrown on
>>> 2898:       // us while we were sleeping. We do not overwrite those.
>>> 2899:       if (!HAS_PENDING_EXCEPTION) {
>> 
>> Maybe not for this bug but we have this `HAS_PENDING_EXCEPTION` check here and further up but I don't see how we can have a pending exception when calling this method. Based on the comment here seems we just wanted to check the async ones as added now.
>
> Should we always have `HAS_PENDING_EXCEPTION == true` if async exception was installed?
> If so, then this newly added check is not really needed:
> 
>            if (!thread->has_async_exception_condition()) {

Until we process the async exception handshake operation, `HAS_PENDING_EXCEPTION` will be false. The only way for `HAS_PENDING_EXCEPTION` to be true would be if we already entered the method with a pending exception, but I don?t see how that is possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2248080447

From sspitsyn at openjdk.org  Sat Aug  2 04:21:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Aug 2025 04:21:54 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <Ci_ghq96Gr9rvBiRyA03gDvm958HGPANPME27TOIj6I=.a4097777-0ae1-4fe8-95c3-21dc6815ec68@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
 <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>
 <Ci_ghq96Gr9rvBiRyA03gDvm958HGPANPME27TOIj6I=.a4097777-0ae1-4fe8-95c3-21dc6815ec68@github.com>
Message-ID: <EhWU1LT4_7C4XHTajwU_0NKptPBoRXdn8l3VPZb_6TA=.d3c0f479-91e8-438c-b937-97d910771fac@github.com>

On Fri, 1 Aug 2025 14:06:41 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Should we always have `HAS_PENDING_EXCEPTION == true` if async exception was installed?
>> If so, then this newly added check is not really needed:
>> 
>>            if (!thread->has_async_exception_condition()) {
>
> Until we process the async exception handshake operation, `HAS_PENDING_EXCEPTION` will be false. The only way for `HAS_PENDING_EXCEPTION` to be true would be if we already entered the method with a pending exception, but I don?t see how that is possible.

Okay, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2249114695

From sspitsyn at openjdk.org  Sat Aug  2 04:24:59 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Aug 2025 04:24:59 GMT
Subject: Integrated: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException
In-Reply-To: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
Message-ID: <Xwm0UYjKWNwYTfuoWx_uYthzEMOvdcPLmQBIZ4bV8aQ=.40f0f0d7-6352-49b8-bfab-9e4742f683ba@github.com>

On Thu, 17 Jul 2025 10:12:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`.
> 
> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`.
> 
> There are a couple of concerns with this fix which would be nice to sort out with reviewers:
> 1.  The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue)
> 2.  The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess`
> 
> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`.
> 
> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it.
> 
> Testing:
>  - Mach5 tiers 1-6 are passed
>  - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest`

This pull request has now been integrated.

Changeset: e801e513
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e801e51311b3fb89bb08620dd5604c7ba9aed9df
Stats:     14 lines in 3 files changed: 4 ins; 4 del; 6 mod

8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException

Reviewed-by: pchilanomate, alanb

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

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

From dholmes at openjdk.org  Sat Aug  2 07:00:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 2 Aug 2025 07:00:59 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <EhWU1LT4_7C4XHTajwU_0NKptPBoRXdn8l3VPZb_6TA=.d3c0f479-91e8-438c-b937-97d910771fac@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
 <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>
 <Ci_ghq96Gr9rvBiRyA03gDvm958HGPANPME27TOIj6I=.a4097777-0ae1-4fe8-95c3-21dc6815ec68@github.com>
 <EhWU1LT4_7C4XHTajwU_0NKptPBoRXdn8l3VPZb_6TA=.d3c0f479-91e8-438c-b937-97d910771fac@github.com>
Message-ID: <UYiH8x0c19PPGnMk2ou5yQqhj6u8yCcOTjOPvPesT9M=.7cbd2e1f-d39a-458a-9279-036e9ff7da8e@github.com>

On Sat, 2 Aug 2025 04:19:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Until we process the async exception handshake operation, `HAS_PENDING_EXCEPTION` will be false. The only way for `HAS_PENDING_EXCEPTION` to be true would be if we already entered the method with a pending exception, but I don?t see how that is possible.
>
> Okay, thanks!

I'm pretty sure that once-upon-a-time we would install any async exception in the `ThreadBlockInVM` destructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2249149459

From dholmes at openjdk.org  Sat Aug  2 07:05:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 2 Aug 2025 07:05:59 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <7LrTOiuQ3p-wZPtvdr-WkDPFzEawcmEeXzEtaIaJTrk=.5e74eda0-5414-4b13-935e-75f6f2a3f486@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <7LrTOiuQ3p-wZPtvdr-WkDPFzEawcmEeXzEtaIaJTrk=.5e74eda0-5414-4b13-935e-75f6f2a3f486@github.com>
Message-ID: <gSbD1dbSSdiQuRjyGsRh6iL0MLAqQZRBAK65DX3LmV0=.cb27028f-b78a-4450-85b4-0e23a1ec5af2@github.com>

On Fri, 1 Aug 2025 09:42:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> David, do you have any concerns or suggestions? Should I wait for your approval?

Sorry I was out of action for a couple of days. I'm happy to see the change to `sleep_nanos` restored. The change seems fine in the current state.

Though I have to wonder if there is any other non-directly-interruptible native blocking I/O operation that directly checks the interrupt flag and thus would see the stop request that way. Need to see if any Java library native code uses JNI to check the interrupt state.

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

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3146280109

From dholmes at openjdk.org  Mon Aug  4 02:25:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 02:25:37 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
Message-ID: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>

TBD

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

Commit messages:
 - Make os::snprintf "nodiscard" and adjust final callsites
 - Convert os::snprintf() to os::snprintf_checked() where appropriate.
 - Forbid C library snprintf
 - Change return-value using snprintf to explicit os::snprintf
 - Change raw snprintf to os::snprintf_checked, whereever truncation would not
 - Change os::snprintf_checked to be void function.
 - Mark os::vsnprintf as nodiscard and update the callsites.

Changes: https://git.openjdk.org/jdk/pull/26470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26470&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347707
  Stats: 197 lines in 46 files changed: 15 ins; 5 del; 177 mod
  Patch: https://git.openjdk.org/jdk/pull/26470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26470/head:pull/26470

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

From jjiang at openjdk.org  Mon Aug  4 07:43:35 2025
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 4 Aug 2025 07:43:35 GMT
Subject: RFR: 8364597: Replace THL A29 Limited with Tencent
Message-ID: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>

`THL A29 Limited` was a `Tencent` company but was dissolved.
So, the copyright notes just use `Tencent` directly.

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

Commit messages:
 - 8364597: Replace THL A29 Limited with Tencent

Changes: https://git.openjdk.org/jdk/pull/26614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364597
  Stats: 67 lines in 58 files changed: 0 ins; 9 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/26614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26614/head:pull/26614

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

From cjplummer at openjdk.org  Mon Aug  4 13:59:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 4 Aug 2025 13:59:58 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v2]
In-Reply-To: <oSfPQcHLf_QOJyS3byj45YQ8p5ilF7QVsnjBWm1_mac=.60d75b20-d9ca-499b-b129-0f3d50fbc5c6@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <oSfPQcHLf_QOJyS3byj45YQ8p5ilF7QVsnjBWm1_mac=.60d75b20-d9ca-499b-b129-0f3d50fbc5c6@github.com>
Message-ID: <_Jvhx7-dNhILfRzEAXORsp2i4s5TCK8oKXO7pmljDnc=.8ae87d2c-2381-41a4-8bcc-fa67b891add0@github.com>

On Thu, 31 Jul 2025 09:51:35 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update exec_md.c
>   
>   correct an compilation error

I added some comments. Testing needs to be done on all of the following

test/hotspot/jtreg/vmTestbase/nsk/jdi
test/hotspot/jtreg/vmTestbase/nsk/jdb
test/hotspot/jtreg/vmTestbase/nsk/jdwp
test/jdk/com/sun/jdi

Are you able to test all supported platforms (linux-x64, linux-aarch64, macosx-x64, macosx-aarch64, windows-x64)? If you can't, I'll download your patch and run the changes through our CI.

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 127:

> 125:     /* Close all file descriptors that have been copied over
> 126:      * from the parent process due to fork(). */
> 127:     if (markDescriptorsCloseOnExec() != 1) { /* failed,  close the old way */

Lines 135 to 138 need to be updated below. Since we are no longer calling closeDescriptors(), STDERR_FILENO +1 and +2 are no longer already closed. The comment needs updating, and you need to set `i` to  `STDERR_FILENO + 1`. Also, you should test this code by forcing markDescriptorsCloseOnExec() to always fail.

I'd also suggest doing a test run with a JDI_ASSERT(JNI_FALSE) if markDescriptorsCloseOnExec() fails. If FD_CLOEXEC is supported, it should always be succeeding.

Also, the "old way" in childproc.c still uses FD_CLOEXEC. The only difference is rather than iterating over the directory contents it instead just iterates over every possible fd. So it never makes use of close() as is being done below.

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

Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26568#pullrequestreview-3084199267
PR Review Comment: https://git.openjdk.org/jdk/pull/26568#discussion_r2251485425

From cjplummer at openjdk.org  Mon Aug  4 18:20:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 4 Aug 2025 18:20:00 GMT
Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT
 errors [v2]
In-Reply-To: <VFUmi77jp-bOiaK-tdgv25d_bjysaRv9xbksSHa7pVU=.5adbf371-ecf9-46d5-88e4-5ba5149266c2@github.com>
References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com>
 <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com>
 <XZmaaMCY9qgHMH3jBJ4h2wPFzTDa83ihgYhgpBTl1y0=.49a5086d-e186-4791-ad79-cfd92788829b@github.com>
 <VFUmi77jp-bOiaK-tdgv25d_bjysaRv9xbksSHa7pVU=.5adbf371-ecf9-46d5-88e4-5ba5149266c2@github.com>
Message-ID: <2Ezvg5oPWE_MGb2WEcLPV1hpj3ANa8JPzMfrM07VjIA=.af92be12-4764-4581-a336-db4b3113cbd8@github.com>

On Fri, 25 Jul 2025 05:45:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I think, this issue needs a Release Note, same as the JNI related enhancement. Not sure about the JVMTI related spec update as it has pure spec clarifications which do not have even minor compatibility issues.
> 
> I agree. Also one release note to cover the 3 interfaces would be clearer than separate notes.

Keep in mind that the APIs in question do not map 1-to-1 across these interfaces. For example, NativeMethodException is unique to JDI, and JDI get/setValue() is implemented such that it cannot end up failing due to NativeMethodException. Also, JDI needed implementation changes whereas JVMTI and JDWP did not.

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

PR Comment: https://git.openjdk.org/jdk/pull/26336#issuecomment-3119584702

From dcubed at openjdk.org  Mon Aug  4 23:31:09 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 23:31:09 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v3]
In-Reply-To: <vT0yfqcx3CoiSOSKVrs0x9JNcud9uX6VchSyMk3sTG8=.052828eb-0e6b-4629-944a-69f2de4ff4fb@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <vT0yfqcx3CoiSOSKVrs0x9JNcud9uX6VchSyMk3sTG8=.052828eb-0e6b-4629-944a-69f2de4ff4fb@github.com>
Message-ID: <QpFMDMMRZ98B5iLM6o0kN9VUpEgURtymeOq0eq4-Fx4=.bed04d25-c5f4-42d8-96f5-cabc169c433b@github.com>

On Mon, 4 Aug 2025 19:53:24 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [12.517s][info][cpu] === CPU time Statistics =============================================================
>> [12.517s][info][cpu]                                                                             CPUs
>> [12.517s][info][cpu]                                                                s       %  utilized
>> [12.517s][info][cpu]    Process
>> [12.517s][info][cpu]      Total                                              175.7628  100.00      14.0
>> [12.517s][info][cpu]      VM Thread                                            7.0000    3.98       0.6
>> [12.517s][info][cpu]      Garbage Collection                                  72.0000   40.96       5.8
>> [12.517s][info][cpu]        GC Threads                                        70.0000   39.83       5.6
>> [12.517s][info][cpu]        VM Thread                                          1.0000    0.57       0.1
>> [12.518s][info][cpu]        String Deduplication                               0.0000    0.00       0.0
>> [12.518s][info][cpu] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefer returning 0 over +/-inf,nan

Seems like JVM/TI folks will be interested also.

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

PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3152782164

From ghan at openjdk.org  Tue Aug  5 10:32:42 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 5 Aug 2025 10:32:42 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v3]
In-Reply-To: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
Message-ID: <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>

> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - a small fix
 - Merge remote-tracking branch 'upstream/master' into 8364312
 - Update exec_md.c
   
   correct an compilation error
 - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
   
   Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26568/files
  - new: https://git.openjdk.org/jdk/pull/26568/files/2e94cb44..cd14e763

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

  Stats: 10540 lines in 250 files changed: 6867 ins; 3006 del; 667 mod
  Patch: https://git.openjdk.org/jdk/pull/26568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26568/head:pull/26568

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

From ghan at openjdk.org  Tue Aug  5 10:35:07 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 5 Aug 2025 10:35:07 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v2]
In-Reply-To: <_Jvhx7-dNhILfRzEAXORsp2i4s5TCK8oKXO7pmljDnc=.8ae87d2c-2381-41a4-8bcc-fa67b891add0@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <oSfPQcHLf_QOJyS3byj45YQ8p5ilF7QVsnjBWm1_mac=.60d75b20-d9ca-499b-b129-0f3d50fbc5c6@github.com>
 <_Jvhx7-dNhILfRzEAXORsp2i4s5TCK8oKXO7pmljDnc=.8ae87d2c-2381-41a4-8bcc-fa67b891add0@github.com>
Message-ID: <RVMsW7xI0R-cfOL3_DrkIOy4UHNbK1ma3i-IeIhnOOE=.4029daf9-3bc7-4426-9c5c-0c4b80e1975c@github.com>

On Mon, 4 Aug 2025 13:57:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update exec_md.c
>>   
>>   correct an compilation error
>
> I added some comments. Testing needs to be done on all of the following
> 
> test/hotspot/jtreg/vmTestbase/nsk/jdi
> test/hotspot/jtreg/vmTestbase/nsk/jdb
> test/hotspot/jtreg/vmTestbase/nsk/jdwp
> test/jdk/com/sun/jdi
> 
> Are you able to test all supported platforms (linux-x64, linux-aarch64, macosx-x64, macosx-aarch64, windows-x64)? If you can't, I'll download your patch and run the changes through our CI.

Hi @plummercj , thank you for the review and comments. I've updated the PR and will run the required tests on linux-x64. I currently don't have access to the other platforms (linux-aarch64, macosx-x64, macosx-aarch64, windows-x64), so I'd appreciate it if you could help run the patch through your CI .

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

PR Comment: https://git.openjdk.org/jdk/pull/26568#issuecomment-3154639450

From cjplummer at openjdk.org  Tue Aug  5 20:36:03 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 5 Aug 2025 20:36:03 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v3]
In-Reply-To: <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
Message-ID: <VYnKMcBos1y6qc7na8kJAlDYLEv1O1-IeDpIxaBPDqk=.2ee50fe1-f921-4a5b-a681-1a9370e30e11@github.com>

On Tue, 5 Aug 2025 10:32:42 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - a small fix
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - Update exec_md.c
>    
>    correct an compilation error
>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>    
>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

Looks good and passes all my CI testing. Note I can't test AIX.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26568#pullrequestreview-3089634860

From ghan at openjdk.org  Wed Aug  6 00:52:04 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Wed, 6 Aug 2025 00:52:04 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v3]
In-Reply-To: <VYnKMcBos1y6qc7na8kJAlDYLEv1O1-IeDpIxaBPDqk=.2ee50fe1-f921-4a5b-a681-1a9370e30e11@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
 <VYnKMcBos1y6qc7na8kJAlDYLEv1O1-IeDpIxaBPDqk=.2ee50fe1-f921-4a5b-a681-1a9370e30e11@github.com>
Message-ID: <LSCvE7Nsf2CM8-ocQBi3Uij_JbSv0G7wjnpjGFIsYqw=.b638078d-1e2c-447e-b74f-d0c7bd7eacd1@github.com>

On Tue, 5 Aug 2025 20:33:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - a small fix
>>  - Merge remote-tracking branch 'upstream/master' into 8364312
>>  - Update exec_md.c
>>    
>>    correct an compilation error
>>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>>    
>>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Looks good and passes all my CI testing. Note I can't test AIX.

Hi @plummercj , thanks again for your help.

Just to confirm ? does your CI testing include linux-x64? I ran the tests locally on that platform, and some of them failed with timeout errors, which might be related to my machine?s performance.

Also, since this PR is marked with /reviewers 2, should I look for another reviewer to help meet the integration requirements? Do you happen to know someone familiar with this area who might be a good candidate?

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

PR Comment: https://git.openjdk.org/jdk/pull/26568#issuecomment-3157059596

From jiefu at openjdk.org  Wed Aug  6 06:59:02 2025
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 6 Aug 2025 06:59:02 GMT
Subject: RFR: 8364597: Replace THL A29 Limited with Tencent
In-Reply-To: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
References: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
Message-ID: <08Gigv9qz5H5c80w-WLegQ_8KVI4xoY-kZ374S8t5ls=.35ded307-c917-4c1b-9ab0-032499140a67@github.com>

On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `THL A29 Limited` was a `Tencent` company but was dissolved.
> So, the copyright notes just use `Tencent` directly.

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26614#pullrequestreview-3090664823

From kevinw at openjdk.org  Wed Aug  6 10:58:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Aug 2025 10:58:04 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v3]
In-Reply-To: <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
Message-ID: <eQLrMxkVkgLNr3qORg-pBGCkjpC_mtO88fjZcYXCctQ=.d3c41f10-f928-4d23-8402-1d928ddc6fbd@github.com>

On Tue, 5 Aug 2025 10:32:42 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - a small fix
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - Update exec_md.c
>    
>    correct an compilation error
>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>    
>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

Hi -

(The code duplication from src/java.base/unix/native/libjava/childproc.c is unfortunate but maybe it's hard to avoid.)

exec_md.c has the existing closeDescriptors() that "returns 0 on failure and 1 on success." which is unusual and unfortunate as zero is a typical success value.

As this is only used locally, this should be an opportunity to change that, and have the new markDescriptorsCloseOnExec() return more normal values, like 0 for success and -1 for failure (like in childproc.c which this borrows from).
(Unless Chris disagrees or sees wider usage...)


Another existing problem:
forkedChildProcess() comments that it will: "Close all file descriptors that have been copied over"
But it calls closeDescriptors() which says it: "Closes every file descriptor that is listed as a directory"

Can we make the comments consistent while we are here? 8-)

The comments before forkedChildProcess() at line 118 and within it at 124 talk about actual closing, not marking as close on exec.

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

PR Review: https://git.openjdk.org/jdk/pull/26568#pullrequestreview-3092000666

From kevinw at openjdk.org  Wed Aug  6 11:02:03 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Aug 2025 11:02:03 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v3]
In-Reply-To: <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
Message-ID: <DAaQlWQxNOOneRrlDRirNyIONv56yJuik79HOSFmP28=.4ee9fb3c-46fe-461e-944d-7d51574f4071@github.com>

On Tue, 5 Aug 2025 10:32:42 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - a small fix
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - Update exec_md.c
>    
>    correct an compilation error
>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>    
>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 59:

> 57: #else
> 58:   #define FD_DIR "/proc/self/fd"
> 59: #endif

Nitpicking, but this FD_DIR define now has a function between its definition here, and where it's used in markDescriptorsCloseOnExec.  It would make sense to move it down to be just before that function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26568#discussion_r2256793737

From ghan at openjdk.org  Wed Aug  6 12:14:50 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Wed, 6 Aug 2025 12:14:50 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v4]
In-Reply-To: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
Message-ID: <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>

> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

Guanqiang Han 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 six additional commits since the last revision:

 - update some comments
 - Merge remote-tracking branch 'upstream/master' into 8364312
 - a small fix
 - Merge remote-tracking branch 'upstream/master' into 8364312
 - Update exec_md.c
   
   correct an compilation error
 - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
   
   Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26568/files
  - new: https://git.openjdk.org/jdk/pull/26568/files/cd14e763..43363d34

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

  Stats: 601 lines in 38 files changed: 356 ins; 117 del; 128 mod
  Patch: https://git.openjdk.org/jdk/pull/26568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26568/head:pull/26568

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

From ghan at openjdk.org  Wed Aug  6 12:20:06 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Wed, 6 Aug 2025 12:20:06 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v3]
In-Reply-To: <eQLrMxkVkgLNr3qORg-pBGCkjpC_mtO88fjZcYXCctQ=.d3c41f10-f928-4d23-8402-1d928ddc6fbd@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
 <eQLrMxkVkgLNr3qORg-pBGCkjpC_mtO88fjZcYXCctQ=.d3c41f10-f928-4d23-8402-1d928ddc6fbd@github.com>
Message-ID: <UaDxojQjY6damrP-RgyVX5fj4g1RLSxnv6mhPtmqftg=.3c838fd2-3c6a-4f1d-ab44-e8090a2b83c0@github.com>

On Wed, 6 Aug 2025 10:55:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - a small fix
>>  - Merge remote-tracking branch 'upstream/master' into 8364312
>>  - Update exec_md.c
>>    
>>    correct an compilation error
>>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>>    
>>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Hi -
> 
> (The code duplication from src/java.base/unix/native/libjava/childproc.c is unfortunate but maybe it's hard to avoid.)
> 
> exec_md.c has the existing closeDescriptors() that "returns 0 on failure and 1 on success." which is unusual and unfortunate as zero is a typical success value.
> 
> As this is only used locally, this should be an opportunity to change that, and have the new markDescriptorsCloseOnExec() return more normal values, like 0 for success and -1 for failure (like in childproc.c which this borrows from).
> (Unless Chris disagrees or sees wider usage...)
> 
> 
> Another existing problem:
> forkedChildProcess() comments that it will: "Close all file descriptors that have been copied over"
> But it calls closeDescriptors() which says it: "Closes every file descriptor that is listed as a directory"
> 
> Can we make the comments consistent while we are here? 8-)
> 
> The comments before forkedChildProcess() at line 118 and within it at 124 talk about actual closing, not marking as close on exec.

Hi @kevinjwalls, thank you for the detailed feedback ? much appreciated!

I agree with your suggestions and have updated the PR accordingly.

Please take another look when you have a moment.

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

PR Comment: https://git.openjdk.org/jdk/pull/26568#issuecomment-3159927768

From cjplummer at openjdk.org  Wed Aug  6 13:10:03 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 6 Aug 2025 13:10:03 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v3]
In-Reply-To: <LSCvE7Nsf2CM8-ocQBi3Uij_JbSv0G7wjnpjGFIsYqw=.b638078d-1e2c-447e-b74f-d0c7bd7eacd1@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
 <VYnKMcBos1y6qc7na8kJAlDYLEv1O1-IeDpIxaBPDqk=.2ee50fe1-f921-4a5b-a681-1a9370e30e11@github.com>
 <LSCvE7Nsf2CM8-ocQBi3Uij_JbSv0G7wjnpjGFIsYqw=.b638078d-1e2c-447e-b74f-d0c7bd7eacd1@github.com>
Message-ID: <L8ThwNOFX8NWL_0ppUBUXRPqEF1u296WUUjtnVhBLjY=.c9748dd5-d46c-416d-b27d-781fab56b916@github.com>

On Wed, 6 Aug 2025 00:49:22 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Just to confirm ? does your CI testing include linux-x64? I ran the tests locally on that platform, and some of them failed with timeout errors, which might be related to my machine?s performance.

I tested linux-x64-debug. If you are seeing timeouts, you should do test runs without any of your changes to see whether or not your changes introduced the timeouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/26568#issuecomment-3160107236

From sroy at openjdk.org  Wed Aug  6 13:43:17 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 6 Aug 2025 13:43:17 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into cpuprocessload
 - Merge branch 'master' into cpuprocessload
 - Update UnixOperatingSystem.c
 - Merge branch 'openjdk:master' into cpuprocessload
 - cleanup
 - system cpu load
 -  restore problem list
 - cpu process load

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

Changes: https://git.openjdk.org/jdk/pull/25332/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=02
  Stats: 79 lines in 2 files changed: 73 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332

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

From kevinw at openjdk.org  Wed Aug  6 13:50:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Aug 2025 13:50:04 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v4]
In-Reply-To: <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>
Message-ID: <OGhDCQW6X61pxK_WSUfvzApCDzl79zDYjccCh4xWMPs=.87a3fdfc-8467-47d9-98e8-23893b107ee0@github.com>

On Wed, 6 Aug 2025 12:14:50 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Guanqiang Han 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 six additional commits since the last revision:
> 
>  - update some comments
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - a small fix
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - Update exec_md.c
>    
>    correct an compilation error
>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>    
>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

Thanks for the updates, looks good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26568#pullrequestreview-3092673233

From mbaesken at openjdk.org  Wed Aug  6 13:51:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Aug 2025 13:51:04 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
Message-ID: <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>

On Wed, 6 Aug 2025 13:43:17 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into cpuprocessload
>  - Merge branch 'master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - cleanup
>  - system cpu load
>  -  restore problem list
>  - cpu process load

test/jdk/ProblemList.txt line 558:

> 556: 
> 557: 
> 558: com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java     8364314 generic-all

Wondering - why is that added ? Is it intended ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2257230418

From cjplummer at openjdk.org  Wed Aug  6 14:10:08 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 6 Aug 2025 14:10:08 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v4]
In-Reply-To: <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>
Message-ID: <sCfWTygZSeqBOdVgHhqNYGoRAUsncU7lAVQ0_ZaXG3k=.1671d82e-78bc-4d06-96af-cba197152cb1@github.com>

On Wed, 6 Aug 2025 12:14:50 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Guanqiang Han 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 six additional commits since the last revision:
> 
>  - update some comments
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - a small fix
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - Update exec_md.c
>    
>    correct an compilation error
>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>    
>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26568#pullrequestreview-3092796677

From sroy at openjdk.org  Wed Aug  6 14:13:05 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 6 Aug 2025 14:13:05 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
 <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>
Message-ID: <3Vwjg-ioaRzQHhcP2VoZTnDl9SSLk2BLlsoJ22Gia44=.5222663d-8705-47cc-a060-2b57f92f119a@github.com>

On Wed, 6 Aug 2025 13:48:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into cpuprocessload
>>  - Merge branch 'master' into cpuprocessload
>>  - Update UnixOperatingSystem.c
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - cleanup
>>  - system cpu load
>>  -  restore problem list
>>  - cpu process load
>
> test/jdk/ProblemList.txt line 558:
> 
>> 556: 
>> 557: 
>> 558: com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java     8364314 generic-all
> 
> Wondering - why is that added ? Is it intended ?

@MBaesken it was part of master branch. shall I remove it ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2257317031

From mbaesken at openjdk.org  Wed Aug  6 14:17:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Aug 2025 14:17:04 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <3Vwjg-ioaRzQHhcP2VoZTnDl9SSLk2BLlsoJ22Gia44=.5222663d-8705-47cc-a060-2b57f92f119a@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
 <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>
 <3Vwjg-ioaRzQHhcP2VoZTnDl9SSLk2BLlsoJ22Gia44=.5222663d-8705-47cc-a060-2b57f92f119a@github.com>
Message-ID: <t9JTli2Hboqs_ee-wUgti4h-Z5ofL2XjogYAmkr8FPs=.eb1845c7-e743-49a0-8002-82ab7d63bb50@github.com>

On Wed, 6 Aug 2025 14:10:44 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 558:
>> 
>>> 556: 
>>> 557: 
>>> 558: com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java     8364314 generic-all
>> 
>> Wondering - why is that added ? Is it intended ?
>
> @MBaesken it was part of master branch. shall I remove it ?

Did not expect this in your PR .
Bit unsure why it is there.

It is not here https://github.com/openjdk/jdk/blob/master/test/jdk/ProblemList.txt  so  why is it needed in your PR ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2257330020

From duke at openjdk.org  Wed Aug  6 15:01:04 2025
From: duke at openjdk.org (duke)
Date: Wed, 6 Aug 2025 15:01:04 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v4]
In-Reply-To: <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>
Message-ID: <82YJseYlesSJdYY910tP-F5nGa3KfleMRshV_aouPl8=.9a9b429d-d41d-4408-8138-3943dc3b640d@github.com>

On Wed, 6 Aug 2025 12:14:50 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Guanqiang Han 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 six additional commits since the last revision:
> 
>  - update some comments
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - a small fix
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - Update exec_md.c
>    
>    correct an compilation error
>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>    
>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

@hgqxjj 
Your change (at version 43363d34c5c0c05e7d3e4f85763ac8a720f781c6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26568#issuecomment-3160531410

From ghan at openjdk.org  Wed Aug  6 15:05:06 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Wed, 6 Aug 2025 15:05:06 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v3]
In-Reply-To: <L8ThwNOFX8NWL_0ppUBUXRPqEF1u296WUUjtnVhBLjY=.c9748dd5-d46c-416d-b27d-781fab56b916@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <W1vJoA9nHJrUUjRdqlDV1VgO5d9eoOTdofkF95ziAm4=.b2a2d39d-59a6-4c2e-b307-00f2da2c5f39@github.com>
 <VYnKMcBos1y6qc7na8kJAlDYLEv1O1-IeDpIxaBPDqk=.2ee50fe1-f921-4a5b-a681-1a9370e30e11@github.com>
 <LSCvE7Nsf2CM8-ocQBi3Uij_JbSv0G7wjnpjGFIsYqw=.b638078d-1e2c-447e-b74f-d0c7bd7eacd1@github.com>
 <L8ThwNOFX8NWL_0ppUBUXRPqEF1u296WUUjtnVhBLjY=.c9748dd5-d46c-416d-b27d-781fab56b916@github.com>
Message-ID: <9QC2WdVGWQcOsVMzpUlB99EQyAbIUtSsYC8UXFqGOuE=.b277fc58-367b-4ef9-9b22-7bcc08f80780@github.com>

On Wed, 6 Aug 2025 13:07:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi @plummercj , thanks again for your help.
>> 
>> Just to confirm ? does your CI testing include linux-x64? I ran the tests locally on that platform, and some of them failed with timeout errors, which might be related to my machine?s performance.
>> 
>> Also, since this PR is marked with /reviewers 2, should I look for another reviewer to help meet the integration requirements? Do you happen to know someone familiar with this area who might be a good candidate?
>
>> Just to confirm ? does your CI testing include linux-x64? I ran the tests locally on that platform, and some of them failed with timeout errors, which might be related to my machine?s performance.
> 
> I tested linux-x64-debug. If you are seeing timeouts, you should do test runs without any of your changes to see whether or not your changes introduced the timeouts.

Hi @plummercj and @kevinjwalls 

Thank you both for your reviews and approvals ? much appreciated!

Please sponsor this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/26568#issuecomment-3160544303

From sroy at openjdk.org  Wed Aug  6 15:08:18 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 6 Aug 2025 15:08:18 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <t9JTli2Hboqs_ee-wUgti4h-Z5ofL2XjogYAmkr8FPs=.eb1845c7-e743-49a0-8002-82ab7d63bb50@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
 <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>
 <3Vwjg-ioaRzQHhcP2VoZTnDl9SSLk2BLlsoJ22Gia44=.5222663d-8705-47cc-a060-2b57f92f119a@github.com>
 <t9JTli2Hboqs_ee-wUgti4h-Z5ofL2XjogYAmkr8FPs=.eb1845c7-e743-49a0-8002-82ab7d63bb50@github.com>
Message-ID: <z6jl1VCywh4C1W_6JPu9leQ5WuTgOK5koOWggNP0jSA=.f308ab3c-b480-45cd-98ca-42abe4fb7398@github.com>

On Wed, 6 Aug 2025 14:14:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> @MBaesken it was part of master branch. shall I remove it ?
>
> Did not expect this in your PR .
> Bit unsure why it is there.
> 
> It is not here https://github.com/openjdk/jdk/blob/master/test/jdk/ProblemList.txt  so  why is it needed in your PR ?

@MBaesken  Not sure. It was showing as a conflict due a change from master, so I thought to keep it. Will remove it then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2257492886

From sroy at openjdk.org  Wed Aug  6 15:08:18 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 6 Aug 2025 15:08:18 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v4]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

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

  Update ProblemList.txt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25332/files
  - new: https://git.openjdk.org/jdk/pull/25332/files/80a6dba6..e4c076f7

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

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

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

From kevinw at openjdk.org  Wed Aug  6 15:40:15 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Aug 2025 15:40:15 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v4]
In-Reply-To: <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>
Message-ID: <pOGfsblwvrl5N176-c0AKwLpkcXy87MhDUmvPZ1_cQI=.cbad3778-9d5b-4dd4-86ad-91ecce7921b0@github.com>

On Wed, 6 Aug 2025 12:14:50 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> Guanqiang Han 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 six additional commits since the last revision:
> 
>  - update some comments
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - a small fix
>  - Merge remote-tracking branch 'upstream/master' into 8364312
>  - Update exec_md.c
>    
>    correct an compilation error
>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>    
>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

If you reproduce a timeout in your local run and it does relate to this change, please update here.
But I ran the above test list locally on linux-x64 and saw no issues.  Looks like we have all done some testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/26568#issuecomment-3160663786

From ghan at openjdk.org  Wed Aug  6 15:40:16 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Wed, 6 Aug 2025 15:40:16 GMT
Subject: Integrated: 8364312: debug agent should set FD_CLOEXEC flag rather
 than explicitly closing every open file
In-Reply-To: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
Message-ID: <yFtwOL-iqHhVC1Eht3rReJO0-bRjpr7H38pYuvIFUks=.f3045119-d14a-464e-91bf-5ff737534cba@github.com>

On Thu, 31 Jul 2025 05:49:18 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().

This pull request has now been integrated.

Changeset: f95af744
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f95af744b07a9ec87e2507b3d584cbcddc827bbd
Stats:     65 lines in 1 file changed: 22 ins; 21 del; 22 mod

8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file

Reviewed-by: cjplummer, kevinw

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

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

From ghan at openjdk.org  Thu Aug  7 02:14:22 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 02:14:22 GMT
Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than
 explicitly closing every open file [v4]
In-Reply-To: <pOGfsblwvrl5N176-c0AKwLpkcXy87MhDUmvPZ1_cQI=.cbad3778-9d5b-4dd4-86ad-91ecce7921b0@github.com>
References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com>
 <qg7N1PTngegPxmdcM3bwQPVqgZx1wHL9FPYD01trULQ=.331b179b-b350-4a59-a1e0-2b3831449324@github.com>
 <pOGfsblwvrl5N176-c0AKwLpkcXy87MhDUmvPZ1_cQI=.cbad3778-9d5b-4dd4-86ad-91ecce7921b0@github.com>
Message-ID: <l66PZ_vbJupKQmMMuJhvGVw2JVserhtIFoLVnN6OMhA=.c7aaf0f0-0ca3-4249-a790-cd827a9c9639@github.com>

On Wed, 6 Aug 2025 15:37:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Guanqiang Han 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 six additional commits since the last revision:
>> 
>>  - update some comments
>>  - Merge remote-tracking branch 'upstream/master' into 8364312
>>  - a small fix
>>  - Merge remote-tracking branch 'upstream/master' into 8364312
>>  - Update exec_md.c
>>    
>>    correct an compilation error
>>  - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
>>    
>>    Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec().
>
> If you reproduce a timeout in your local run and it does relate to this change, please update here.
> But I ran the above test list locally on linux-x64 and saw no issues.  Looks like we have all done some testing.

@kevinjwalls Thank you for the sponsorship !

I re-ran the tests several times today on my local Linux x64 machine and didn't observe any timeouts. It's likely that the earlier timeout I encountered was due to limited resources on my virtual machine. Everything looks good now.

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

PR Comment: https://git.openjdk.org/jdk/pull/26568#issuecomment-3162182935

From stuefe at openjdk.org  Thu Aug  7 05:39:17 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 05:39:17 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v4]
In-Reply-To: <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
Message-ID: <sHCvgmsnNbRTcLaUCuQctBVWoDhr8RvBgedviW4J_pE=.9cd3d230-bb34-439e-b5ec-65eddb043be2@github.com>

On Wed, 6 Aug 2025 15:08:18 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update ProblemList.txt

> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
> 

Who? me? Other Reviewers? Strange PR description ;-)

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3162562129

From lmesnik at openjdk.org  Thu Aug  7 05:54:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 7 Aug 2025 05:54:53 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode
Message-ID: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>

The fix added JVMTI stress testing mode.

This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.

I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.

The agent has 2 modes now:
 - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
 - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 

The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
Note, that flagless tests are excluded automatically and not executed in this mode.

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

Commit messages:
 - problemlist and exclusion fiexd.
 - fixed IR framework
 - Merge branch 'master' of https://github.com/openjdk/jdk into jvmti-stress-agent
 - fixed small issues
 - Revert "updated struct to c++"
 - Merge branch 'master' of https://github.com/openjdk/jdk into jvmti-stress-agent
 - fixed vm death
 - updated struct to c++
 - lib updated
 - more fixes
 - ... and 7 more: https://git.openjdk.org/jdk/compare/7e484e2a...cb9c6457

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

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

From stuefe at openjdk.org  Thu Aug  7 06:06:17 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 06:06:17 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v4]
In-Reply-To: <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
Message-ID: <k6YJ-kXZ1Gb37iQiFmuHUvtizBUid7aJYomT1TqL5Gs=.f562f73e-e3d1-447f-a9e3-09ac9cf5a1e4@github.com>

On Wed, 6 Aug 2025 15:08:18 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update ProblemList.txt

Changes requested by stuefe (Reviewer).

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 43:

> 41: static perfstat_cpu_total_t cpu_total_old;
> 42: static time_t last_sample_time = 0;
> 43: static double last_cpu_load = -1.0;

Not threadsafe. What happens if you call this concurrently from multiple threads? Visibility of these three values can be in any order of updates. You'd get skewed values.

Check out how Linux does it. They use mutexes to synchronize access to this function.

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 54:

> 52:     if (initialized && (now - last_sample_time < 5)) {
> 53:         return last_cpu_load; // Return cached value if less than 5s
> 54:     }

Are you sure this is needed? How slow is perfstat_cpu_total?

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 102:

> 100:         prev_timebase = curr_stats.last_timebase;
> 101:         initialized = 1;
> 102:         return -1.0;

Here, and above in the other function: this seems wrong and would result in the first measurement to be off (or very large if displayed as unsigned).

See how Linux does it in perfInit().

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

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3095405436
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2259126398
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2259127887
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2259157137

From stuefe at openjdk.org  Thu Aug  7 06:06:18 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 06:06:18 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v4]
In-Reply-To: <k6YJ-kXZ1Gb37iQiFmuHUvtizBUid7aJYomT1TqL5Gs=.f562f73e-e3d1-447f-a9e3-09ac9cf5a1e4@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>
 <k6YJ-kXZ1Gb37iQiFmuHUvtizBUid7aJYomT1TqL5Gs=.f562f73e-e3d1-447f-a9e3-09ac9cf5a1e4@github.com>
Message-ID: <9IAX8fOEqLRoOeFdOR1lNTcFTtlipeXO5as2BFahcpg=.b40d3fac-17cd-4f0d-ad6c-5c59902042a4@github.com>

On Thu, 7 Aug 2025 05:46:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update ProblemList.txt
>
> src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 43:
> 
>> 41: static perfstat_cpu_total_t cpu_total_old;
>> 42: static time_t last_sample_time = 0;
>> 43: static double last_cpu_load = -1.0;
> 
> Not threadsafe. What happens if you call this concurrently from multiple threads? Visibility of these three values can be in any order of updates. You'd get skewed values.
> 
> Check out how Linux does it. They use mutexes to synchronize access to this function.

Style nit, you may want to group these together into a nice structure, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2259142734

From duke at openjdk.org  Thu Aug  7 09:49:12 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 7 Aug 2025 09:49:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v4]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [12.517s][info][cpu] === CPU time Statistics =============================================================
> [12.517s][info][cpu]                                                                             CPUs
> [12.517s][info][cpu]                                                                s       %  utilized
> [12.517s][info][cpu]    Process
> [12.517s][info][cpu]      Total                                              175.7628  100.00      14.0
> [12.517s][info][cpu]      VM Thread                                            7.0000    3.98       0.6
> [12.517s][info][cpu]      Garbage Collection                                  72.0000   40.96       5.8
> [12.517s][info][cpu]        GC Threads                                        70.0000   39.83       5.6
> [12.517s][info][cpu]        VM Thread                                          1.0000    0.57       0.1
> [12.518s][info][cpu]        String Deduplication                               0.0000    0.00       0.0
> [12.518s][info][cpu] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Improve robustness

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/216ba811..3f552362

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

  Stats: 29 lines in 3 files changed: 23 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

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

From erikj at openjdk.org  Thu Aug  7 13:20:20 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Aug 2025 13:20:20 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <6i_NUjWgiZ71wdex51k2-J86RrWhOeb7T4Z1qHxq_9g=.3cf3fbeb-6953-4eb7-a988-62bc750136c0@github.com>

On Thu, 17 Jul 2025 02:39:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

make/RunTests.gmk line 64:

> 62: 
> 63: AGENT_PREFIX := lib
> 64: AGENT_EXT := .so

We already have `LIBRARY_PREFIX` and `SHARED_LIBRARY_SUFFIX` defined in spec.gmk. To make those available in a test prebuilt scenario, they need to also be defined in RunTestPrebuiltSpec.gmk. Then you can use those instead of defining these.

make/RunTests.gmk line 215:

> 213: $(eval $(call ParseKeywordVariable, JTREG, \
> 214:     SINGLE_KEYWORDS := JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT \
> 215:         TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY JVMTI_STRESS_AGENT MAX_MEM RUN_PROBLEM_LISTS \

Could you add this list element in a way that doesn't make the lines any longer?

make/RunTests.gmk line 892:

> 890:     $1_JTREG_BASIC_OPTIONS += $$(addprefix $$(JTREG_PROBLEM_LIST_PREFIX), $$(wildcard \
> 891: 	$$(addprefix $$($1_TEST_ROOT)/, ProblemList-jvmti-stress-agent.txt) \
> 892:     ))

Please use regular parentheses when referencing variables in makefiles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2260294410
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2260298782
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2260294596

From lmesnik at openjdk.org  Thu Aug  7 22:18:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 7 Aug 2025 22:18:43 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v2]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <Bc_ZpN43x_dt_hqP4m9tjGs_EtmuUnOIUO0YGK8rlfQ=.b77601f6-1375-4dfa-9627-89ff50558853@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

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

  makefiles fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/cb9c6457..6d505a8b

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

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

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

From lmesnik at openjdk.org  Thu Aug  7 22:18:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 7 Aug 2025 22:18:44 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v2]
In-Reply-To: <6i_NUjWgiZ71wdex51k2-J86RrWhOeb7T4Z1qHxq_9g=.3cf3fbeb-6953-4eb7-a988-62bc750136c0@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <6i_NUjWgiZ71wdex51k2-J86RrWhOeb7T4Z1qHxq_9g=.3cf3fbeb-6953-4eb7-a988-62bc750136c0@github.com>
Message-ID: <1kiR2G4snYm5hhiyTqxz_YmmR0X7-VmLWbnSQuSc_XM=.ec06f4bc-d465-4364-a8d1-f223762e2b84@github.com>

On Thu, 7 Aug 2025 13:14:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   makefiles fixed
>
> make/RunTests.gmk line 64:
> 
>> 62: 
>> 63: AGENT_PREFIX := lib
>> 64: AGENT_EXT := .so
> 
> We already have `LIBRARY_PREFIX` and `SHARED_LIBRARY_SUFFIX` defined in spec.gmk. To make those available in a test prebuilt scenario, they need to also be defined in RunTestPrebuiltSpec.gmk. Then you can use those instead of defining these.

Thanks for suggestion!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2261561101

From jjiang at openjdk.org  Fri Aug  8 02:31:15 2025
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 8 Aug 2025 02:31:15 GMT
Subject: Integrated: 8364597: Replace THL A29 Limited with Tencent
In-Reply-To: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
References: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
Message-ID: <lUxnGf2cVXWfHR38WmZQVPwfzfBnjtOcc2Re_omkeGw=.c64c63b7-e7dd-48e1-b6f7-f0a1ebefaf56@github.com>

On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `THL A29 Limited` was a `Tencent` company but was dissolved.
> So, the copyright notes just use `Tencent` directly.

This pull request has now been integrated.

Changeset: 4c9eadda
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c9eaddaef83c6ba30e27ae3e0d16caeeec206cb
Stats:     67 lines in 58 files changed: 0 ins; 9 del; 58 mod

8364597: Replace THL A29 Limited with Tencent

Reviewed-by: jiefu

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

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

From rsunderbabu at openjdk.org  Fri Aug  8 09:40:24 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Fri, 8 Aug 2025 09:40:24 GMT
Subject: RFR: 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 frequently fails with SerialGC
Message-ID: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>

VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue. During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.

Testing: Tiers1,2,3 and other ties where the test runs.

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

Commit messages:
 - 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java frequently fails with SerialGC

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

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

From duke at openjdk.org  Fri Aug  8 13:09:42 2025
From: duke at openjdk.org (Lei Zhu)
Date: Fri, 8 Aug 2025 13:09:42 GMT
Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate
 VM flags [v2]
In-Reply-To: <sfMcesDrfgGXonjkPPs5aHMF1FW0Cac0kkvgRC0HjOY=.227e3d2a-ac8a-448c-abe2-8d763be97b18@github.com>
References: <hokO-PHPwP02HfNEz1i6M97mIDwk2j0A7V381Ou7kic=.cf075bd0-7ca6-4523-98f6-d89c57d5f1d2@github.com>
 <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com>
 <sfMcesDrfgGXonjkPPs5aHMF1FW0Cac0kkvgRC0HjOY=.227e3d2a-ac8a-448c-abe2-8d763be97b18@github.com>
Message-ID: <GqmYCd06B_cojldt6bt9isNfoQHirII6d8VxYjDfKNU=.59e17f5c-273d-4499-8184-3b6bd13298e9@github.com>

On Thu, 31 Jul 2025 13:11:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove duplicate -cp
>
> Looks good.
> (More than trivial, but good. 8-) )

@kevinjwalls Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26555#issuecomment-3148349512

From erikj at openjdk.org  Fri Aug  8 13:33:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Aug 2025 13:33:15 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v2]
In-Reply-To: <Bc_ZpN43x_dt_hqP4m9tjGs_EtmuUnOIUO0YGK8rlfQ=.b77601f6-1375-4dfa-9627-89ff50558853@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <Bc_ZpN43x_dt_hqP4m9tjGs_EtmuUnOIUO0YGK8rlfQ=.b77601f6-1375-4dfa-9627-89ff50558853@github.com>
Message-ID: <zlHIYInt8Zb9LtJb8RCY0kTg5aCBHuVENoahJwWvBH0=.f2095a0e-4973-4682-84ed-740a1c7fe4bb@github.com>

On Thu, 7 Aug 2025 22:18:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   makefiles fixed

make/RunTests.gmk line 73:

> 71:   endif
> 72: endif
> 73: 

What happened here?

make/RunTests.gmk line 874:

> 872:     $1_JTREG_BASIC_OPTIONS += $$(addprefix $$(JTREG_PROBLEM_LIST_PREFIX), $$(wildcard \
> 873: 	$$(addprefix $$($1_TEST_ROOT)/, ProblemList-jvmti-stress-agent.txt) \
> 874:     ))

You need to add the definitions of `LIBRARY_PREFIX` and `SHARED_LIBRARY_SUFFIX` for this to work in a remote testing situation.

I asked you to not use `{}` but `()` when referencing variables in makefiles.

There is no continuation indentation here, please adjust.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2262972522
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2262984228

From cjplummer at openjdk.org  Fri Aug  8 14:21:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 8 Aug 2025 14:21:17 GMT
Subject: RFR: 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 frequently fails with SerialGC
In-Reply-To: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
References: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
Message-ID: <igwpweeSKNcZAGqeloIADzgXs5Yxwbip-K-jG53OL4s=.fddd0e98-a506-4771-af0c-4f3d41dcaa45@github.com>

On Fri, 8 Aug 2025 09:32:51 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue. During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

The changes are fine, but I'm not so sure it is appropriate to use JDK-8313655 for this PR. Perhaps create a subtask to re-enable SerialGC use, and close JDK-8313655 as "Cannot Reproduce"

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

PR Review: https://git.openjdk.org/jdk/pull/26690#pullrequestreview-3101036718

From rsunderbabu at openjdk.org  Sat Aug  9 02:18:25 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Sat, 9 Aug 2025 02:18:25 GMT
Subject: RFR: 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 frequently fails with SerialGC
In-Reply-To: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
References: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
Message-ID: <-mfxynujKG2a7Rx6fSZtduqymXvOuZy6xQImqiW73I4=.4523382a-ce85-48b8-b4b0-dbc8ffda3373@github.com>

On Fri, 8 Aug 2025 09:32:51 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue. During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

I will create another PR for this with appropriate bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/26690#issuecomment-3169660825

From rsunderbabu at openjdk.org  Sat Aug  9 02:18:26 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Sat, 9 Aug 2025 02:18:26 GMT
Subject: Withdrawn: 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 frequently fails with SerialGC
In-Reply-To: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
References: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
Message-ID: <4eQoeVE9loHBFvr30_-qJPLnZEvVko_o645lWJxv1PI=.7cccf392-f6af-4165-a5ef-7640c57e7571@github.com>

On Fri, 8 Aug 2025 09:32:51 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue. During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

This pull request has been closed without being integrated.

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

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

From rsunderbabu at openjdk.org  Sat Aug  9 03:34:30 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Sat, 9 Aug 2025 03:34:30 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
Message-ID: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>

VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.

Testing: Tiers1,2,3 and other ties where the test runs.

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

Commit messages:
 - 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java Re-enable SerialGC flag on debuggee process

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

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

From lmesnik at openjdk.org  Sat Aug  9 17:11:10 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 9 Aug 2025 17:11:10 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
In-Reply-To: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
References: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
Message-ID: <Rswh6lxqrKkn3UX_6ltI5lg9OJZ1xFA8y3OD-ChAj6g=.24c47c16-789e-4f60-bb33-3fe6e3928835@github.com>

On Sat, 9 Aug 2025 03:27:26 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26711#pullrequestreview-3103148814

From cjplummer at openjdk.org  Sat Aug  9 18:51:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 9 Aug 2025 18:51:09 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
In-Reply-To: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
References: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
Message-ID: <57h-7acHOmEpH5iOC8KXRiPoXx8SmpNfW_CE4zvoYQI=.37ca57a2-afd0-44d6-a79d-b3daf8548822@github.com>

On Sat, 9 Aug 2025 03:27:26 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

Looks good. BTW, you could have still used the old PR and just changed the title to reflect the new CR.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26711#pullrequestreview-3103206850

From duke at openjdk.org  Sat Aug  9 19:57:09 2025
From: duke at openjdk.org (Philippe Marschall)
Date: Sat, 9 Aug 2025 19:57:09 GMT
Subject: RFR: 8364281: Reduce JNI usage in Linux attach provider
Message-ID: <mbMJm3KARNBwPiPOijsTFWXWMQif4GyAAqvvZqUTh54=.d778bc6d-2fb6-48e4-9c51-402215cc479e@github.com>

Reduce the usage of JNI in the Linux attach provider by making more use of the `Path` API.

- use the `Path` API to read file permissions
- use the `Path` API  to write to and read from Unix domain sockets
- use JDK internal APIs to access the euid and eguid

After this the sole usage of JNI in the Linux attach provider will be to send a signal using `kill`.

I ran the tier1 and serviceability test suites and they both pass. I verified I can attach to and attach using a locally built JDK. I didn't do any Docker related tests.

I split the changes into two commits:

- The first commit ports the permission check code more or less directly from C to Java using integer based checks.
- The second commit changes the permission check code to use higher level Java abstractions (`UserPrincipal`, `Set`, ...)

I hope this makes it easier to review and verify the changes preserve the semantics.

To the best of my knowledge `uid_t` is an unsigned 32 bit integer. `VM#geteuid()` returns it as `long`, unsigned. However `UnixUserPrincipals#fromUid` expects an `int`, I believe casting is the correct way to convert in this case.

I tried to keep unrelated changes to `VirtualMachineImpl` to a minimum. I did however replace all usages of `java.io.File` with `java.nio.file.Path` and made two methods `static`. We could get rid of the `socket_path` instance variable if we instead use `socket_address` to flag a disconnect.

Ultimately the same changes can be applied to the macOS an AIX implementations.

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

Commit messages:
 - 8364281: Reduce JNI usage in Linux attach provider
 - 8364281: Reduce JNI usage in Linux attach provider

Changes: https://git.openjdk.org/jdk/pull/26712/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26712&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364281
  Stats: 337 lines in 3 files changed: 45 ins; 242 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/26712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26712/head:pull/26712

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

From lmesnik at openjdk.org  Sat Aug  9 20:36:51 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 9 Aug 2025 20:36:51 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state
Message-ID: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>

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.

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

Commit messages:
 - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state

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

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

From duke at openjdk.org  Sun Aug 10 02:25:22 2025
From: duke at openjdk.org (duke)
Date: Sun, 10 Aug 2025 02:25:22 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
In-Reply-To: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
References: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
Message-ID: <aoaSuYf6jWm-DSIadUXwABlguAZsr8uIBuUyDe4Kmj4=.da625844-3ebf-4f1d-a5c5-5d996524b3e0@github.com>

On Sat, 9 Aug 2025 03:27:26 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

@rsunderbabu 
Your change (at version 93b4cbefde03500f53f53516ede6b31650b31118) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26711#issuecomment-3172309271

From lmesnik at openjdk.org  Sun Aug 10 06:09:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 10 Aug 2025 06:09:00 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

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

  fixed makefiles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/6d505a8b..49c2a67d

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

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

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

From duke at openjdk.org  Mon Aug 11 07:34:10 2025
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 11 Aug 2025 07:34:10 GMT
Subject: RFR: 8364281: Reduce JNI usage in Linux attach provider
In-Reply-To: <mbMJm3KARNBwPiPOijsTFWXWMQif4GyAAqvvZqUTh54=.d778bc6d-2fb6-48e4-9c51-402215cc479e@github.com>
References: <mbMJm3KARNBwPiPOijsTFWXWMQif4GyAAqvvZqUTh54=.d778bc6d-2fb6-48e4-9c51-402215cc479e@github.com>
Message-ID: <eBYCoXDYBsiWWckl5fIMLFK3f994sA25Vv6hJ6VsR0M=.bd441759-5471-4a75-a6de-13666393281a@github.com>

On Sat, 9 Aug 2025 19:50:14 GMT, Philippe Marschall <duke at openjdk.org> wrote:

> Reduce the usage of JNI in the Linux attach provider by making more use of the `Path` API.
> 
> - use the `Path` API to read file permissions
> - use the `Path` API  to write to and read from Unix domain sockets
> - use JDK internal APIs to access the euid and eguid
> 
> After this the sole usage of JNI in the Linux attach provider will be to send a signal using `kill`.
> 
> I ran the tier1 and serviceability test suites and they both pass. I verified I can attach to and attach using a locally built JDK. I didn't do any Docker related tests.
> 
> I split the changes into two commits:
> 
> - The first commit ports the permission check code more or less directly from C to Java using integer based checks.
> - The second commit changes the permission check code to use higher level Java abstractions (`UserPrincipal`, `Set`, ...)
> 
> I hope this makes it easier to review and verify the changes preserve the semantics.
> 
> To the best of my knowledge `uid_t` is an unsigned 32 bit integer. `VM#geteuid()` returns it as `long`, unsigned. However `UnixUserPrincipals#fromUid` expects an `int`, I believe casting is the correct way to convert in this case.
> 
> I tried to keep unrelated changes to `VirtualMachineImpl` to a minimum. I did however replace all usages of `java.io.File` with `java.nio.file.Path` and made two methods `static`. We could get rid of the `socket_path` instance variable if we instead use `socket_address` to flag a disconnect.
> 
> Ultimately the same changes can be applied to the macOS an AIX implementations.

Thanks for the work so far, nice to get rid of JNI. :slightly_smiling_face: 

There is a [problemlisted test](https://github.com/openjdk/jdk/pull/21417) related to this that could make sense to run manually (https://bugs.openjdk.org/browse/JDK-8341518, it's failing in Oracle's CI but I have not been able to reproduce the failure myself, discussed a bit in https://github.com/openjdk/jdk/pull/21331 too).

I'll see if I can find time to check out this change locally and run some tests, otherwise, feel free to run it yourself.

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

PR Comment: https://git.openjdk.org/jdk/pull/26712#issuecomment-3173574572

From ihse at openjdk.org  Mon Aug 11 09:30:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:30:16 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
Message-ID: <KQRRnWEp_65HO7lDY2KTW3FopxsZ2iGKHrFZqzFLamo=.164014c6-ce13-4d57-873f-742df4cc7d96@github.com>

On Sun, 10 Aug 2025 06:09:00 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed makefiles

make/RunTests.gmk line 882:

> 880:   ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
> 881:     AGENT := $$(LIBRARY_PREFIX)JvmtiStressAgent$$(SHARED_LIBRARY_SUFFIX)=$$(JTREG_JVMTI_STRESS_AGENT)
> 882:     $1_JTREG_BASIC_OPTIONS += -javaoption:'-agentpath:${TEST_IMAGE_DIR}/hotspot/jtreg/native/$${AGENT}'

Suggestion:

    $1_JTREG_BASIC_OPTIONS += -javaoption:'-agentpath:$(TEST_IMAGE_DIR)/hotspot/jtreg/native/$$(AGENT)'

make/RunTests.gmk line 885:

> 883:     $1_JTREG_BASIC_OPTIONS += $$(addprefix $$(JTREG_PROBLEM_LIST_PREFIX), $$(wildcard \
> 884: 	$$(addprefix $$($1_TEST_ROOT)/, ProblemList-jvmti-stress-agent.txt) \
> 885:     ))

Suggestion:

	    $$(addprefix $$($1_TEST_ROOT)/, ProblemList-jvmti-stress-agent.txt) \
        ))


Also, the comment on line length applies here.

test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp line 38:

> 36:  * Test supports 2 modes:
> 37:  *   - standard, where the agent doesn't require debugging capabilities
> 38:  *   - debug, where the agent  additionally test debug-related functionality

Suggestion:

 *   - debug, where the agent additionally test debug-related functionality

test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp line 40:

> 38:  *   - debug, where the agent  additionally test debug-related functionality
> 39:  *   The debug mode is incompatible with debugger tests and debug jvmti tests.
> 40:  *   The standard mode should be compatible with all tests except probelmlisted.

Suggestion:

 *   The standard mode should be compatible with all tests except problemlisted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266130714
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266133869
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266137865
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266138425

From ihse at openjdk.org  Mon Aug 11 09:30:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:30:17 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <KQRRnWEp_65HO7lDY2KTW3FopxsZ2iGKHrFZqzFLamo=.164014c6-ce13-4d57-873f-742df4cc7d96@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
 <KQRRnWEp_65HO7lDY2KTW3FopxsZ2iGKHrFZqzFLamo=.164014c6-ce13-4d57-873f-742df4cc7d96@github.com>
Message-ID: <FW4kGj0stWUxMeTQHwNYex2jDHcyjNiYD9IjzSvxHec=.41d1c18c-3909-46b6-8392-05603cf940e9@github.com>

On Mon, 11 Aug 2025 09:24:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed makefiles
>
> make/RunTests.gmk line 882:
> 
>> 880:   ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
>> 881:     AGENT := $$(LIBRARY_PREFIX)JvmtiStressAgent$$(SHARED_LIBRARY_SUFFIX)=$$(JTREG_JVMTI_STRESS_AGENT)
>> 882:     $1_JTREG_BASIC_OPTIONS += -javaoption:'-agentpath:${TEST_IMAGE_DIR}/hotspot/jtreg/native/$${AGENT}'
> 
> Suggestion:
> 
>     $1_JTREG_BASIC_OPTIONS += -javaoption:'-agentpath:$(TEST_IMAGE_DIR)/hotspot/jtreg/native/$$(AGENT)'

Also, this line looks quite long. Can you check that it does not pass 80 characters? (Can't tell on github reviews...)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266132846

From ihse at openjdk.org  Mon Aug 11 09:38:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:38:12 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
Message-ID: <6BPt_Y_57yRWLC6iksvVGg3SkPKM98UAasfCcrAPFeo=.99d5dd24-39b4-4935-89c0-ff17aecd4b20@github.com>

On Sun, 10 Aug 2025 06:09:00 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed makefiles

make/RunTests.gmk line 881:

> 879: 
> 880:   ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
> 881:     AGENT := $$(LIBRARY_PREFIX)JvmtiStressAgent$$(SHARED_LIBRARY_SUFFIX)=$$(JTREG_JVMTI_STRESS_AGENT)

I don't understand the usage scenario here. Are you supposed to run this like `make test JTREG=JVMTI_STRESS_AGENT=true`? If so, this will result in `-javaoption:'-agentpath:<test-image>/hotspot/jtreg/native/libJvmtiStressAgent.so=true` being sent to jtreg, and that looks sus. 

Or how should this be used? 

In fact, this option should be described in testing.md.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266155034

From mbaesken at openjdk.org  Mon Aug 11 11:58:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Aug 2025 11:58:29 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
Message-ID: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>

When using asan - enabled binaries, the following tests fail (on Linux x86_64).
This one uses ulimit in a way problematic with asan :
vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java

 ```
stdout: [];
 stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v

 exitValue = 134


This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
tools/launcher/TooSmallStackSize.java

PASSED: got expected error message with stack size of 16k
PASSED: got expected error message with stack size of 64k
Test output:
*** exitValue = 139
FAILED: VM failed to launch with minimum allowed stack size of 136k

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

Commit messages:
 - JDK-8365240

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

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

From jsjolen at openjdk.org  Mon Aug 11 16:04:00 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 11 Aug 2025 16:04:00 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable
Message-ID: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>

Hi,

This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.

I didn't change any copyright years for this change.

Thanks

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

Commit messages:
 - Rename file
 - Rename ResourceHashtable to HashTable

Changes: https://git.openjdk.org/jdk/pull/26729/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365264
  Stats: 1841 lines in 67 files changed: 856 ins; 856 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/26729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729

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

From jsjolen at openjdk.org  Mon Aug 11 17:32:11 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 11 Aug 2025 17:32:11 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <m99dOANXZzBqMUZ5L6W4Gjgwc9oRfTTZ3oTmmmN0FX0=.de28b77d-98b9-4ea7-8033-6c1d80ba539d@github.com>

On Mon, 11 Aug 2025 15:57:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Aha, of course I forgot about re-sorting the headers.

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

PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3176028919

From lmesnik at openjdk.org  Mon Aug 11 19:35:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 11 Aug 2025 19:35:11 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
Message-ID: <oO0w2mjzbdgtkBcmvrBsHQN_MCxTKZR6PVWZUt2JTRQ=.3e5d7937-ed6a-4306-804c-10f73bcb3bd8@github.com>

On Sun, 10 Aug 2025 06:09:00 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed makefiles

Thank you feedback, I explained the usage of 
 JTREG_JVMTI_STRESS_AGENT
and applied your changes.

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

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3107474883

From lmesnik at openjdk.org  Mon Aug 11 19:35:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 11 Aug 2025 19:35:13 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <6BPt_Y_57yRWLC6iksvVGg3SkPKM98UAasfCcrAPFeo=.99d5dd24-39b4-4935-89c0-ff17aecd4b20@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
 <6BPt_Y_57yRWLC6iksvVGg3SkPKM98UAasfCcrAPFeo=.99d5dd24-39b4-4935-89c0-ff17aecd4b20@github.com>
Message-ID: <4zzzq381JNv2-LyGnqTZwxz1eLe-VPlqVcoF08Qw2V4=.ea35f8d3-c109-4614-8244-cf4a6f407f49@github.com>

On Mon, 11 Aug 2025 09:35:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed makefiles
>
> make/RunTests.gmk line 881:
> 
>> 879: 
>> 880:   ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
>> 881:     AGENT := $$(LIBRARY_PREFIX)JvmtiStressAgent$$(SHARED_LIBRARY_SUFFIX)=$$(JTREG_JVMTI_STRESS_AGENT)
> 
> I don't understand the usage scenario here. Are you supposed to run this like `make test JTREG=JVMTI_STRESS_AGENT=true`? If so, this will result in `-javaoption:'-agentpath:<test-image>/hotspot/jtreg/native/libJvmtiStressAgent.so=true` being sent to jtreg, and that looks sus. 
> 
> Or how should this be used? 
> 
> In fact, this option should be described in testing.md.

This is a jtreg agent options, I use it like
JTREG_JVMTI_STRESS_AGENT=debugger=false
or
JTREG_JVMTI_STRESS_AGENT=debugger=true,verbose
Any of options enable jvmti agent and parsed by it. 
I don't want to add 2 options, for hits. The JTREG_JVMTI_STRESS_AGENT=false doesn't make any sense. 

The options are defined by stress agent while makefile just propagate them to the agent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2267818671

From lmesnik at openjdk.org  Mon Aug 11 19:42:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 11 Aug 2025 19:42:13 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <MDTaRBhA3Sm7TH8B647RYyPhjUqq4KEpltnW78YHvwY=.bb4124b3-0674-4c59-818d-675f7bfd994e@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26725#pullrequestreview-3107524814

From sspitsyn at openjdk.org  Mon Aug 11 21:11:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 11 Aug 2025 21:11:10 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
In-Reply-To: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
References: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
Message-ID: <zJeIned-9F1s3AAG2AbbPwRCyjrFk_fjhJQqVQpihPc=.3f6ab4c9-8dfc-4337-8dcc-2a70a5227d7b@github.com>

On Sat, 9 Aug 2025 03:27:26 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26711#pullrequestreview-3107784107

From sspitsyn at openjdk.org  Tue Aug 12 03:43:09 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Aug 2025 03:43:09 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <5-h_mFm-MT1hN0eyE3LIlssveIKitDmFBf0iDrke7Es=.6c480926-9735-4bbf-822b-d65f8f40d9d3@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26725#pullrequestreview-3108442923

From sspitsyn at openjdk.org  Tue Aug 12 03:54:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Aug 2025 03:54:12 GMT
Subject: RFR: 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: <ZbmGBSuF4uxX_2LWF_bZ7UbnOILGHNZp7WmwjlmomYU=.d6ff1e57-08d0-43c0-a67a-9e99e1d69854@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.

Thank you for catching and addressing this! How was the fix tested?
It looks okay at a glance but may give surprises.

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

PR Review: https://git.openjdk.org/jdk/pull/26713#pullrequestreview-3108454887

From lmesnik at openjdk.org  Tue Aug 12 05:54:19 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 12 Aug 2025 05:54:19 GMT
Subject: RFR: 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: <jD9FnDE7kUi0mh3_dz1M8TOL1iTBJTQwf8GCAE-034Q=.120f9d8e-eb95-4b28-83d0-cc3c6cb1805c@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.

I ran tier1-5 testing and separately verified that test pass with jvmti strass agent.

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

PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3177804637

From duke at openjdk.org  Tue Aug 12 06:02:29 2025
From: duke at openjdk.org (Cheng Pan)
Date: Tue, 12 Aug 2025 06:02:29 GMT
Subject: RFR: 8318706: Implement JEP 423: Region Pinning for G1 [v10]
In-Reply-To: <JdqgKJ0U8tUAk6qo8EMdIz0fXQCH9sNmghnURl6JyG8=.6d2a9670-ab74-486d-8d04-23694a5d02db@github.com>
References: <zgkDxCTh91bqzCWSsJXHgkWv67H-1TXKNXDMDfdHAMA=.506f99bf-9106-4d70-9c33-c878a5bf311c@github.com>
 <ooKtyjZzxIe4Xb3HKR2egSFxkvBqF6VLflbcjpp-N7I=.a7353ee1-4976-4c4d-a628-bce810984649@github.com>
 <1-i3-5OmZbuCNUlpfv31Kr3eiBXEd4Si8F5gsbPHuBQ=.1d97dcac-4662-4482-842c-ce86315ba61a@github.com>
 <JdqgKJ0U8tUAk6qo8EMdIz0fXQCH9sNmghnURl6JyG8=.6d2a9670-ab74-486d-8d04-23694a5d02db@github.com>
Message-ID: <zMdAerV6aTuiroOFbMknHqwXMnzO0jBFl45RvEsm710=.4cb607a8-51b6-417c-95ca-356baf888c5f@github.com>

On Wed, 29 Nov 2023 10:02:31 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Marked as reviewed by ayang (Reviewer).
>
> Thanks @albertnetymk @kstefanj @walulyai for your reviews! Given that the JEP is now targeted, I will integrate.
> 
> This has been a fairly long journey until today... :)

@tschatzl thanks for your excellent work! I know that JEP 423 targets JDK 22, but I wonder if this can be backported to JDK 21. For big data workloads like Apache Spark, we do see that G1 generally performs better than other GC algorithms, but one major issue is that it heavily uses JNI for compression/decompression (e.g. [zstd-jni](https://github.com/luben/zstd-jni/issues/346)), thus easy to OOM. 

I have tested some internal Spark jobs, which were easy to OOM on JDK 21, work well on JDK 22, but given that JDK 22 has been EOL, I would appreciate it if this could be landed on JDK 21

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

PR Comment: https://git.openjdk.org/jdk/pull/16342#issuecomment-3177810965

From mbaesken at openjdk.org  Tue Aug 12 07:20:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 07:20:17 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <afhwH3pzzKafxrmAwvVMjyXrbofPKc2M4NlBL9VMghI=.ee16b736-6164-4e8d-bb4f-a7143cb6b325@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26725#issuecomment-3178007009

From mbaesken at openjdk.org  Tue Aug 12 07:20:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 07:20:17 GMT
Subject: Integrated: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <AVTBCNs7xSKFFFJVQa31cO3Hr62OkNNGfd0k7Vx0hyk=.1031daa7-66af-4975-91d3-1f2c029ea537@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

This pull request has now been integrated.

Changeset: d78fa5a9
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d78fa5a9f6254e2e93e75c693efba75e09736749
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8365240: [asan] exclude some tests when using asan enabled binaries

Reviewed-by: lmesnik, sspitsyn

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

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

From jsjolen at openjdk.org  Tue Aug 12 07:53:58 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 12 Aug 2025 07:53:58 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v2]
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <mHhs1WqspGpuC60gVOPC_Bp7cOuNt98lFhfSalC8-J4=.cc04e2b6-2af2-4b09-932d-6f38ae6f7d21@github.com>

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  What does the test think about this sorting?

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26729/files
  - new: https://git.openjdk.org/jdk/pull/26729/files/fa1794d0..c7ce8dea

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

  Stats: 87 lines in 29 files changed: 42 ins; 45 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729

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

From jsjolen at openjdk.org  Tue Aug 12 10:45:09 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 12 Aug 2025 10:45:09 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v3]
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <QcElZQEd_MYS0yNkkDFsE72uu96FzEz4grNVhvOfrLQ=.ed3309f7-7465-4580-8662-3de9c4e7db1d@github.com>

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  This should be preferred

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26729/files
  - new: https://git.openjdk.org/jdk/pull/26729/files/c7ce8dea..4e143035

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

  Stats: 36 lines in 16 files changed: 18 ins; 16 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729

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

From gziemski at openjdk.org  Tue Aug 12 10:51:13 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 12 Aug 2025 10:51:13 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
Message-ID: <RRnq_S05Y0vnE985bhgi3893QGFmeLC8h6aC1psnzKk=.45f910c0-c361-4c33-95c7-8e80fdfe30f5@github.com>

On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments

Taking a look...

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3178801354

From ayang at openjdk.org  Tue Aug 12 11:56:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 12 Aug 2025 11:56:19 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v4]
In-Reply-To: <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>
Message-ID: <yb3cFaOVf6zr2BJmWU7JElmWaPuGMULPl5mbj6cP97I=.c47904be-f8b4-4b3c-839e-f7b5dc9a9369@github.com>

On Thu, 7 Aug 2025 09:49:12 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve robustness

src/hotspot/os/linux/os_linux.cpp line 4953:

> 4951:       // to detach itself from the VM - which should result in ESRCH.
> 4952:       assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
> 4953:       log_warning(os)("Could not sample thread CPU time");

Maybe diff msgs can be printed so that we know better what went wrong if `-1` is returned.

src/hotspot/share/gc/shared/collectedHeap.cpp line 610:

> 608: }
> 609: 
> 610: double calc_usage(double component_cpu_time, double process_cpu_time) {

Could `percent_of` be used instead?

src/hotspot/share/gc/shared/collectedHeap.cpp line 627:

> 625: 
> 626:   LogTarget(Info, cpu) cpuLog;
> 627:   if (cpuLog.is_enabled()) {

Can use early-return to reduce one indentation level.

src/hotspot/share/gc/shared/collectedHeap.hpp line 468:

> 466:   virtual void gc_threads_do(ThreadClosure* tc) const = 0;
> 467: 
> 468:   jlong elapsed_gc_cpu_time() const;

Seems unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269575257
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269582730
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269586175
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269589768

From jsjolen at openjdk.org  Tue Aug 12 12:02:13 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 12 Aug 2025 12:02:13 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4]
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Found the instructions for how to run the script in the error log

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26729/files
  - new: https://git.openjdk.org/jdk/pull/26729/files/4e143035..5c58e011

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

  Stats: 20 lines in 7 files changed: 10 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729

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

From duke at openjdk.org  Tue Aug 12 12:24:35 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 12 Aug 2025 12:24:35 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Feedback from Albert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/3f552362..143fcacb

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

  Stats: 34 lines in 3 files changed: 2 ins; 7 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

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

From duke at openjdk.org  Tue Aug 12 12:24:37 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 12 Aug 2025 12:24:37 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v4]
In-Reply-To: <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>
Message-ID: <zn5tn_H1CoW9e-5ygaZMZqGGpamrsIGK1tFIR3dM-3s=.d57b900e-9141-4842-9f11-c6f005a153aa@github.com>

On Thu, 7 Aug 2025 09:49:12 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve robustness

Thanks for the review @albertnetymk! I pushed changes reflecting your feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3179095971

From ayang at openjdk.org  Tue Aug 12 15:20:18 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 12 Aug 2025 15:20:18 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
Message-ID: <ScJxz_3oq2-HVbpfLTOAQBMRL89M3ntox_z2__y66sQ=.50bdac15-d68a-4fa1-8c9b-1a1793b05a82@github.com>

On Tue, 12 Aug 2025 12:24:35 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Albert

src/hotspot/share/gc/shared/collectedHeap.cpp line 610:

> 608: }
> 609: 
> 610: double percent_of(double component_cpu_time, double process_cpu_time) {

There is global function, `percent_of`. Can that be used directly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2270240264

From lkorinth at openjdk.org  Tue Aug 12 17:09:32 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 12 Aug 2025 17:09:32 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
Message-ID: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@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 default timeout factor", I have taken a few actions:
1) in testing(md|html): interpreted mode -> forced compilation mode
2) in MTTest.java: changed 1200 -> 400 (was 300 to begin with)

I am now re-running tier 1-8.

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

Commit messages:
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Changes: https://git.openjdk.org/jdk/pull/26749/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8260555
  Stats: 598 lines in 297 files changed: 49 ins; 91 del; 458 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 cjplummer at openjdk.org  Tue Aug 12 17:54:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Aug 2025 17:54:13 GMT
Subject: RFR: 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: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>

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

> 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.

@lkorinth Can you send me a link to the failure?

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3180396310

From ayang at openjdk.org  Tue Aug 12 19:24:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 12 Aug 2025 19:24:15 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4]
In-Reply-To: <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
Message-ID: <TCfUAC7klNvLxuPKGOqNSYxx3mXy6TqS09lI5nNEYkE=.c6e4187e-2d7f-4281-8d66-2b901e0f0ac2@github.com>

On Tue, 12 Aug 2025 12:02:13 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
>> 
>> I didn't change any copyright years for this change.
>> 
>> Thanks
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Found the instructions for how to run the script in the error log

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26729#pullrequestreview-3112432948

From iklam at openjdk.org  Wed Aug 13 00:15:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 13 Aug 2025 00:15:10 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4]
In-Reply-To: <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
Message-ID: <iBjD0epjpW2xtraeXWH46hGnkwbb1oLoRH_OLN7_OZk=.73c35038-1caa-4964-82fc-c9b36b88d4a4@github.com>

On Tue, 12 Aug 2025 12:02:13 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
>> 
>> I didn't change any copyright years for this change.
>> 
>> Thanks
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Found the instructions for how to run the script in the error log

`hashtable.hpp` should become `hashTable.hpp`, which defines the type `HashTable`. (Existing example:  `concurrentHashTable.hpp` defines the type `ConcurrentHashTable`).

`resizeableResourceHash.hpp` should be renamed to `resizeableHashTable.hpp`

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

PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3181661293

From rsunderbabu at openjdk.org  Wed Aug 13 01:03:12 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 13 Aug 2025 01:03:12 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
In-Reply-To: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
References: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
Message-ID: <BZdJMKX_hmg66T-v8mMhl5QWWJAR_VEImMcLM4OgNh8=.b1ba1143-0b66-402a-8520-703c017bf2c0@github.com>

On Sat, 9 Aug 2025 03:27:26 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

Please sponsor the change.

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

PR Comment: https://git.openjdk.org/jdk/pull/26711#issuecomment-3181857896

From rsunderbabu at openjdk.org  Wed Aug 13 01:49:16 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 13 Aug 2025 01:49:16 GMT
Subject: Integrated: 8365184:
 sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java Re-enable SerialGC flag on
 debuggee process
In-Reply-To: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
References: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
Message-ID: <iFUH9h-Gmpjj9HfeGtpnfmKyEbANJMjy8kb0z_5v998=.a22f17c3-8566-4353-845e-b58cd84660f7@github.com>

On Sat, 9 Aug 2025 03:27:26 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

This pull request has now been integrated.

Changeset: 25480f00
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25480f0011297ad209eca1b1b56bcf983ea4ee5d
Stats:     6 lines in 1 file changed: 0 ins; 5 del; 1 mod

8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java Re-enable SerialGC flag on debuggee process

Reviewed-by: lmesnik, cjplummer, sspitsyn

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

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

From syan at openjdk.org  Wed Aug 13 01:50:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:50:14 GMT
Subject: RFR: 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: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@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...

test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Should we need to update the copyright year for the touch files

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

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

From syan at openjdk.org  Wed Aug 13 01:54:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:54:16 GMT
Subject: RFR: 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: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@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...

test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:

> 27:  * @requires vm.debug
> 28:  * @summary Test running with StressRecompilation enabled.
> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation

I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.


> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
55:elapsed time (seconds): 0.581
66:elapsed time (seconds): 0.575
116:elapsed time (seconds): 3.088
162:elapsed time (seconds): 0.001
173:elapsed time (seconds): 11.546

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

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

From sspitsyn at openjdk.org  Wed Aug 13 06:07:21 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 06:07:21 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state
In-Reply-To: <jD9FnDE7kUi0mh3_dz1M8TOL1iTBJTQwf8GCAE-034Q=.120f9d8e-eb95-4b28-83d0-cc3c6cb1805c@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <jD9FnDE7kUi0mh3_dz1M8TOL1iTBJTQwf8GCAE-034Q=.120f9d8e-eb95-4b28-83d0-cc3c6cb1805c@github.com>
Message-ID: <Q3_sTR39M-P5TLERogtc9KcCTwTc2omlQk9VItK3rao=.b33403cd-d195-4a2b-b8f9-3cdffaa44a4e@github.com>

On Tue, 12 Aug 2025 05:51:04 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> I ran tier1-5 testing and separately verified that test pass with jvmti strass agent.

Okay, thanks. I'd also run the tier 6 to be more safe.

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

PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3182306000

From sspitsyn at openjdk.org  Wed Aug 13 06:07:22 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 06:07:22 GMT
Subject: RFR: 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: <gV3o_xzyzUuUvQp9WIKBMUNcxeK7oBgfp7q-z445jnk=.b7df0cd0-da87-4c96-aff0-35f63e0554dc@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.

src/hotspot/share/prims/jvmtiExport.cpp line 1839:

> 1837:   JRT_BLOCK
> 1838:   state = get_jvmti_thread_state(thread);
> 1839:   JRT_BLOCK_END

The `JRT_BLOCK` is defined as:

#define JRT_BLOCK                                                    \
    {                                                                \
    assert(current == JavaThread::current(), "Must be");             \
    ThreadInVMfromJava __tiv(current);                               \
    JavaThread* THREAD = current; /* For exception macros. */        \
    DEBUG_ONLY(VMEntryWrapper __vew;)


I'd suggest something like this instead of using `JRT_BLOCK`:

-  JvmtiThreadState *state = get_jvmti_thread_state(thread);
+   JvmtiThreadState *state = nullptr;
+  {
+     ThreadInVMfromJava __tiv(thread);
+     state = get_jvmti_thread_state(thread);
+  }


Alternatively, the `JRT_BLOCK` can be started at the line 1837 and ended with `JRT_BLOCK_END` at the line 1875. Not sure, what issue we can encounter with this though. At least, it is worth a try.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2272164623

From lmesnik at openjdk.org  Wed Aug 13 06:26:16 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 13 Aug 2025 06:26:16 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v2]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <aLk012827L8UsKveINzXsv7ihBGqTPSioBLSxe4fqn4=.bbeb3689-85fa-46b4-bae3-f126bcb151ab@github.com>

> 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.

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

  simplified after feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/47a32e8c..7cce73e3

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

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

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

From lmesnik at openjdk.org  Wed Aug 13 06:26:17 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 13 Aug 2025 06:26:17 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v2]
In-Reply-To: <gV3o_xzyzUuUvQp9WIKBMUNcxeK7oBgfp7q-z445jnk=.b7df0cd0-da87-4c96-aff0-35f63e0554dc@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <gV3o_xzyzUuUvQp9WIKBMUNcxeK7oBgfp7q-z445jnk=.b7df0cd0-da87-4c96-aff0-35f63e0554dc@github.com>
Message-ID: <f6-RIR8j-_5-mZHYK_AUKTY4vFtyaxPSHyOmhb0h89c=.224136e6-b634-4928-9f58-5a129909f48d@github.com>

On Wed, 13 Aug 2025 06:03:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplified after feedback
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1839:
> 
>> 1837:   JRT_BLOCK
>> 1838:   state = get_jvmti_thread_state(thread);
>> 1839:   JRT_BLOCK_END
> 
> The `JRT_BLOCK` is defined as:
> 
> #define JRT_BLOCK                                                    \
>     {                                                                \
>     assert(current == JavaThread::current(), "Must be");             \
>     ThreadInVMfromJava __tiv(current);                               \
>     JavaThread* THREAD = current; /* For exception macros. */        \
>     DEBUG_ONLY(VMEntryWrapper __vew;)
> 
> 
> I'd suggest something like this instead of using `JRT_BLOCK`:
> 
> -  JvmtiThreadState *state = get_jvmti_thread_state(thread);
> +   JvmtiThreadState *state = nullptr;
> +  {
> +     ThreadInVMfromJava __tiv(thread);
> +     state = get_jvmti_thread_state(thread);
> +  }
> 
> 
> Alternatively, the `JRT_BLOCK` can be started at the line 1837 and ended with `JRT_BLOCK_END` at the line 1875. Not sure, what issue we can encounter with this though. At least, it is worth a try.

As I understand the post_method_entry was called via JRT_BLOCK_ENTRY and not JRT_BLOCK by the reason. We need to be in Java. See comments for the method invocation. 

// This is a JRT_BLOCK_ENTRY because we have to stash away the return oop
// before transitioning to VM, and restore it after transitioning back
// to Java. The return oop at the top-of-stack, is not walked by the GC.
JRT_BLOCK_ENTRY(void, InterpreterRuntime::post_method_exit(JavaThread* current))
  LastFrameAccessor last_frame(current);
  JvmtiExport::post_method_exit(current, last_frame.method(), last_frame.get_frame());
JRT_END

And thanks for simplification, it is a good idea. I've updated the PR.
I am running tier1-8 for Hotspot tests to ensure that nothing is broken.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2272174407

From sspitsyn at openjdk.org  Wed Aug 13 07:19:13 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 07:19:13 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v2]
In-Reply-To: <aLk012827L8UsKveINzXsv7ihBGqTPSioBLSxe4fqn4=.bbeb3689-85fa-46b4-bae3-f126bcb151ab@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <aLk012827L8UsKveINzXsv7ihBGqTPSioBLSxe4fqn4=.bbeb3689-85fa-46b4-bae3-f126bcb151ab@github.com>
Message-ID: <WSKZaH0HfQPeEBHqnEJYN35lZupK-QaKbHhVTNZbC68=.c89f3e9f-d5ca-4feb-88aa-11d3b35806a1@github.com>

On Wed, 13 Aug 2025 06:26:16 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.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified after feedback

looks good

src/hotspot/share/prims/jvmtiExport.cpp line 1837:

> 1835:   JvmtiThreadState *state = nullptr;
> 1836:   {
> 1837:     ThreadInVMfromJava __tiv(thread);

Nit: Maybe rename: `__tiv` => `tiv`. The prefix `__` is normally used in macros to avoid potential naming conflicts.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26713#pullrequestreview-3114238397
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2272301754

From sspitsyn at openjdk.org  Wed Aug 13 07:29:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 07:29:11 GMT
Subject: RFR: 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: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@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...

I've reviewed the Serviceability related tweaks and I'm okay with them in general.
But I'm curious if you do not see any timeouts with this anymore.

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

Marked as reviewed by sspitsyn (Reviewer).

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

From jsjolen at openjdk.org  Wed Aug 13 07:47:05 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 13 Aug 2025 07:47:05 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v5]
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Ioi's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26729/files
  - new: https://git.openjdk.org/jdk/pull/26729/files/5c58e011..eb5a4ea6

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

  Stats: 56 lines in 51 files changed: 0 ins; 0 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/26729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729

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

From jsjolen at openjdk.org  Wed Aug 13 09:30:15 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 13 Aug 2025 09:30:15 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4]
In-Reply-To: <iBjD0epjpW2xtraeXWH46hGnkwbb1oLoRH_OLN7_OZk=.73c35038-1caa-4964-82fc-c9b36b88d4a4@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
 <iBjD0epjpW2xtraeXWH46hGnkwbb1oLoRH_OLN7_OZk=.73c35038-1caa-4964-82fc-c9b36b88d4a4@github.com>
Message-ID: <Y05W9DYpeNTXrJRH4Ko0ZPs8zybf-wXgXLnLOQ9HMSQ=.41b87f6c-9761-4dfa-bbd8-f35e8adf4507@github.com>

On Wed, 13 Aug 2025 00:13:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `hashtable.hpp` should become `hashTable.hpp`, which defines the type `HashTable`. (Existing example: `concurrentHashTable.hpp` defines the type `ConcurrentHashTable`).
> 
> `resizeableResourceHash.hpp` should be renamed to `resizeableHashTable.hpp`

Done!

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

PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3182953039

From aturbanov at openjdk.org  Wed Aug 13 09:47:17 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Aug 2025 09:47:17 GMT
Subject: RFR: 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: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@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...

test/langtools/tools/lib/toolbox/ToolBox.java line 480:

> 478: 
> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;

Suggestion:

    private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

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

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

From sspitsyn at openjdk.org  Wed Aug 13 10:25:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 10:25:35 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v8]
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <Aw1UvQJNysNn1gHHLxEE62WVblWbGbByc8YALMk0PaA=.96bb281f-3caf-48d4-99e2-737c78d89c4a@github.com>

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge
 - Merge
 - Merge
 - Merge
 - review: replace RESERVED flag with UNUSED
 - review: keep right order of the obsoleted VM options
 - corrected one assert message
 - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26232/files
  - new: https://git.openjdk.org/jdk/pull/26232/files/0edab914..df91f171

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

  Stats: 29966 lines in 783 files changed: 17653 ins; 9650 del; 2663 mod
  Patch: https://git.openjdk.org/jdk/pull/26232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232

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

From lkorinth at openjdk.org  Wed Aug 13 13:09:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:09:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
Message-ID: <RA6T2Udma4QM1EdTUlZ9Y4l6Wo1783yEKYgOPy8UOZY=.7938ce78-45a5-4607-9298-72cf19436662@github.com>

On Wed, 13 Aug 2025 01:47:43 GMT, SendaoYan <syan 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: ...
>
> test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Should we need to update the copyright year for the touched files

`After the review, I will update the copyrights.`

It is IMO easier to review big changes without the noise.

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

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

From lkorinth at openjdk.org  Wed Aug 13 13:21:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:21:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
Message-ID: <4q0047gChugbkkv-W0lis2E8nXVWh8YGVJiBehoojLY=.0b9055a2-f038-4247-82a9-7c60ee9f6637@github.com>

On Tue, 12 Aug 2025 17:52:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > 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.
> 
> @lkorinth Can you send me a link to the failure?

I sent it to you on email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3183896453

From erikj at openjdk.org  Wed Aug 13 13:28:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Aug 2025 13:28:18 GMT
Subject: RFR: 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: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@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...

make/RunTests.gmk line 939:

> 937: 
> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.

I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

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

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

From lkorinth at openjdk.org  Wed Aug 13 13:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
Message-ID: <jX2ocV7Rf3mYq7TYfPkxKQfgucnVdhEDYMB91LwhTtI=.8810fb03-295c-4be5-9771-d7e031390002@github.com>

On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan <syan 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: ...
>
> test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:
> 
>> 27:  * @requires vm.debug
>> 28:  * @summary Test running with StressRecompilation enabled.
>> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation
> 
> I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.
> 
> 
>> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
> 55:elapsed time (seconds): 0.581
> 66:elapsed time (seconds): 0.575
> 116:elapsed time (seconds): 3.088
> 162:elapsed time (seconds): 0.001
> 173:elapsed time (seconds): 11.546

I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is.

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

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

From lkorinth at openjdk.org  Wed Aug 13 13:53:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:53:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
Message-ID: <5nc1SBXnwAOJJvnrbMyPIsre61u--GxMHSffdDf8qUU=.77100025-4b9e-4e0a-b71d-df590df5f9ba@github.com>

On Wed, 13 Aug 2025 07:26:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore.

I only got the four timeouts described in the description, I got a few other failures as well that was not timeout related. I sent you a link to the test results in an email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3184026177

From lkorinth at openjdk.org  Wed Aug 13 14:22:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:08 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@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:

  After suggestions from Erik and Andrey

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/ac47dbdc..dbe42964

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

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 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 lkorinth at openjdk.org  Wed Aug 13 14:22:10 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:10 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
Message-ID: <imd2i-VIlFCbEytLUZDyy_1SEU8ebK39Eif8JbdQsTU=.fefa1e8d-027b-445d-be69-07f6c6a475fd@github.com>

On Wed, 13 Aug 2025 13:25:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> make/RunTests.gmk line 939:
> 
>> 937: 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.
> 
> I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

I updated it to "Please reach consensus before changing this. It was not easy changing it to a `1`. " I also did not break the comment as it was shorter than line 933 above it. Is it acceptable now?

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

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

From lkorinth at openjdk.org  Wed Aug 13 14:22:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
Message-ID: <KRJUnB026z2YmEljJJCHz5JEklLTO2LJfpMvwvt6-5k=.8388ace4-c445-4fdc-a71d-dff5a53cbeb6@github.com>

On Wed, 13 Aug 2025 09:44:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 480:
> 
>> 478: 
>> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
>> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;
> 
> Suggestion:
> 
>     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

Fixed!

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

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

From lmesnik at openjdk.org  Wed Aug 13 14:36:48 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 13 Aug 2025 14:36:48 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v3]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <VYHTnX7k12iS960Um5w6FdiI-HbcjjgDEjBnrZaNLzU=.24763be2-31df-4dae-b2fc-4a889b820a9c@github.com>

> 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.

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

  fixed name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/7cce73e3..977c9eb4

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

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

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

From lmesnik at openjdk.org  Wed Aug 13 15:08:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 13 Aug 2025 15:08:55 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v4]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <JFtr3pOjDnihBw7pmCv_NkbY74iB4S6bJw26iU49yIg=.87e555d7-700d-4c4b-8c71-6ec739d9a8b8@github.com>

> 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.

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

 - added _
 - wong phase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/977c9eb4..255c0ba8

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

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

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

From iklam at openjdk.org  Wed Aug 13 15:57:11 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 13 Aug 2025 15:57:11 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v5]
In-Reply-To: <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>
Message-ID: <1IxUyzkDpUinf8oPCbLLRXldc_btUhDSnEcQUEj8ikM=.9f65e529-d65a-461b-aa73-b666eebcaac3@github.com>

On Wed, 13 Aug 2025 07:47:05 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
>> 
>> I didn't change any copyright years for this change.
>> 
>> Thanks
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi's comments

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26729#pullrequestreview-3116642805

From jsjolen at openjdk.org  Wed Aug 13 18:42:19 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 13 Aug 2025 18:42:19 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v5]
In-Reply-To: <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>
Message-ID: <G5395SQOqM_TDe3afc8qLjMhd7xi2vUzWSTY9uxbwa4=.40662d4b-32fb-42e0-bcf1-ff000bdeacd0@github.com>

On Wed, 13 Aug 2025 07:47:05 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
>> 
>> I didn't change any copyright years for this change.
>> 
>> Thanks
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi's comments

Cheers!

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

PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3185064264

From jsjolen at openjdk.org  Wed Aug 13 18:45:21 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 13 Aug 2025 18:45:21 GMT
Subject: Integrated: 8365264: Rename ResourceHashtable to HashTable
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <mXg82pP5OF-UsFOyhb0Lz5dzJDvv97t_KSrm2188lMg=.5c8a1c52-fb22-4e28-b421-9e8ebb3cfd32@github.com>

On Mon, 11 Aug 2025 15:57:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

This pull request has now been integrated.

Changeset: 4680dc98
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4680dc983169d48fcf83eb50dc60e32e79d5d976
Stats:     2233 lines in 71 files changed: 1058 ins; 1059 del; 116 mod

8365264: Rename ResourceHashtable to HashTable

Reviewed-by: iklam, ayang

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

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

From duke at openjdk.org  Wed Aug 13 19:33:11 2025
From: duke at openjdk.org (Philippe Marschall)
Date: Wed, 13 Aug 2025 19:33:11 GMT
Subject: RFR: 8364281: Reduce JNI usage in Linux attach provider
In-Reply-To: <mbMJm3KARNBwPiPOijsTFWXWMQif4GyAAqvvZqUTh54=.d778bc6d-2fb6-48e4-9c51-402215cc479e@github.com>
References: <mbMJm3KARNBwPiPOijsTFWXWMQif4GyAAqvvZqUTh54=.d778bc6d-2fb6-48e4-9c51-402215cc479e@github.com>
Message-ID: <INYTIwPUVB4VtxaTnKisd5yFUszITtm8sX-D27nho9E=.95cc2fa9-c808-4306-919a-4dc3a4a2c2a8@github.com>

On Sat, 9 Aug 2025 19:50:14 GMT, Philippe Marschall <duke at openjdk.org> wrote:

> Reduce the usage of JNI in the Linux attach provider by making more use of the `Path` API.
> 
> - use the `Path` API to read file permissions
> - use the `Path` API  to write to and read from Unix domain sockets
> - use JDK internal APIs to access the euid and eguid
> 
> After this the sole usage of JNI in the Linux attach provider will be to send a signal using `kill`.
> 
> I ran the tier1 and serviceability test suites and they both pass. I verified I can attach to and attach using a locally built JDK. I didn't do any Docker related tests.
> 
> I split the changes into two commits:
> 
> - The first commit ports the permission check code more or less directly from C to Java using integer based checks.
> - The second commit changes the permission check code to use higher level Java abstractions (`UserPrincipal`, `Set`, ...)
> 
> I hope this makes it easier to review and verify the changes preserve the semantics.
> 
> To the best of my knowledge `uid_t` is an unsigned 32 bit integer. `VM#geteuid()` returns it as `long`, unsigned. However `UnixUserPrincipals#fromUid` expects an `int`, I believe casting is the correct way to convert in this case.
> 
> I tried to keep unrelated changes to `VirtualMachineImpl` to a minimum. I did however replace all usages of `java.io.File` with `java.nio.file.Path` and made two methods `static`. We could get rid of the `socket_path` instance variable if we instead use `socket_address` to flag a disconnect.
> 
> Ultimately the same changes can be applied to the macOS an AIX implementations.

> Thanks for the work so far, nice to get rid of JNI. ?
> 
> There is a [problemlisted test](https://github.com/openjdk/jdk/pull/21417) related to this that could make sense to run manually (https://bugs.openjdk.org/browse/JDK-8341518, it's failing in Oracle's CI but I have not been able to reproduce the failure myself, discussed a bit in #21331 too).
> 
> I'll see if I can find time to check out this change locally and run some tests, otherwise, feel free to run it yourself.

TestJcmdWithSideCar fails with

    java.nio.file.NoSuchFileException: /proc/7/cwd/.attach_pid7
	  at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	  at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
	  at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	  at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:856)
	  at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:106)
	  at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
	  at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
	  at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	  at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)

I must confess I'm quite confused by this as this ultimately means that

    Files.createFile(path).toRealPath()

Fails with NoSuchFileException on the Path returned by createFile.

Is there a better way to run TestJcmdWithSideCar other than removing it from ProblemList?

As for the issue on Oralce CI, is there I way I ran run TestJcmdWithSideCar on a feature branch of mine on Oralce CI without opening a PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/26712#issuecomment-3185276826

From sspitsyn at openjdk.org  Wed Aug 13 21:23:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 21:23:11 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v4]
In-Reply-To: <JFtr3pOjDnihBw7pmCv_NkbY74iB4S6bJw26iU49yIg=.87e555d7-700d-4c4b-8c71-6ec739d9a8b8@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <JFtr3pOjDnihBw7pmCv_NkbY74iB4S6bJw26iU49yIg=.87e555d7-700d-4c4b-8c71-6ec739d9a8b8@github.com>
Message-ID: <ItdEacFJVxtLyWDllZ0Ez1WQO3IPSBxgTm_1_bEwuw8=.15cb69fc-b63a-447b-8fea-899eee90dc65@github.com>

On Wed, 13 Aug 2025 15:08:55 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.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added _
>  - wong phase

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26713#pullrequestreview-3117745050

From sspitsyn at openjdk.org  Wed Aug 13 21:23:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 21:23:12 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v2]
In-Reply-To: <WSKZaH0HfQPeEBHqnEJYN35lZupK-QaKbHhVTNZbC68=.c89f3e9f-d5ca-4feb-88aa-11d3b35806a1@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <aLk012827L8UsKveINzXsv7ihBGqTPSioBLSxe4fqn4=.bbeb3689-85fa-46b4-bae3-f126bcb151ab@github.com>
 <WSKZaH0HfQPeEBHqnEJYN35lZupK-QaKbHhVTNZbC68=.c89f3e9f-d5ca-4feb-88aa-11d3b35806a1@github.com>
Message-ID: <fMHDh0TBPYMx3fiKZJpO2CgO8iwHpOOI2fwBkZd8Rkw=.82dea1a5-9f4c-49bb-8225-c0fecd3fd7a0@github.com>

On Wed, 13 Aug 2025 07:16:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplified after feedback
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1837:
> 
>> 1835:   JvmtiThreadState *state = nullptr;
>> 1836:   {
>> 1837:     ThreadInVMfromJava __tiv(thread);
> 
> Nit: Maybe rename: `__tiv` => `tiv`. The prefix `__` is normally used in macros to avoid potential naming conflicts.

Thank you for the update on this!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2274671305

From pchilanomate at openjdk.org  Thu Aug 14 00:04:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 14 Aug 2025 00:04:11 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v4]
In-Reply-To: <JFtr3pOjDnihBw7pmCv_NkbY74iB4S6bJw26iU49yIg=.87e555d7-700d-4c4b-8c71-6ec739d9a8b8@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <JFtr3pOjDnihBw7pmCv_NkbY74iB4S6bJw26iU49yIg=.87e555d7-700d-4c4b-8c71-6ec739d9a8b8@github.com>
Message-ID: <NVQtYP-t8QteXyeudM64_IVtJ0GDw7EkuNdy_Dz915M=.ff178d38-1978-4176-a59b-f46fae169ab3@github.com>

On Wed, 13 Aug 2025 15:08:55 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.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added _
>  - wong phase

src/hotspot/share/prims/jvmtiExport.cpp line 1838:

> 1836:   {
> 1837:     ThreadInVMfromJava tiv(thread);
> 1838:     state = get_jvmti_thread_state(thread);

The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2274899453

From sjohanss at openjdk.org  Thu Aug 14 08:05:17 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 14 Aug 2025 08:05:17 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
Message-ID: <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>

On Tue, 12 Aug 2025 12:24:35 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Albert

Thanks for looking at this and improving the CPU tracking and making it easily accessible. 

Overall I think the change looks good, just a few comments/questions.

src/hotspot/os/linux/os_linux.cpp line 4953:

> 4951:       // to detach itself from the VM - which should result in ESRCH.
> 4952:       assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
> 4953:       log_warning(os)("Could not sample thread CPU time (return code %d)", rc);

Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal?

The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output.

The same goes for the other warnings below.

src/hotspot/share/gc/shared/collectedHeap.cpp line 655:

> 653:   print_tracing_info();
> 654: 
> 655:   log_cpu_time();

As mentioned offline, I would prefer if this was moved away from `CollectedHeap` since it is now not only GC/Heap related times that are tracked. 

We could add a `Universe::before_exit()` which firsts does the CPU logging before calling `heap()->before_exit()`. As long as we do the logging before, would there be any problem with this?

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

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3119416367
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2275777432
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2275805357

From sspitsyn at openjdk.org  Thu Aug 14 09:17:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Aug 2025 09:17:12 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v4]
In-Reply-To: <NVQtYP-t8QteXyeudM64_IVtJ0GDw7EkuNdy_Dz915M=.ff178d38-1978-4176-a59b-f46fae169ab3@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <JFtr3pOjDnihBw7pmCv_NkbY74iB4S6bJw26iU49yIg=.87e555d7-700d-4c4b-8c71-6ec739d9a8b8@github.com>
 <NVQtYP-t8QteXyeudM64_IVtJ0GDw7EkuNdy_Dz915M=.ff178d38-1978-4176-a59b-f46fae169ab3@github.com>
Message-ID: <pzpPPoh1_-WEiv2MTckxvhzPnB7462KIBWf9KuXOBmU=.acad384a-0d46-4d6f-a687-2fd2d903cdff@github.com>

On Thu, 14 Aug 2025 00:01:29 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:
>> 
>>  - added _
>>  - wong phase
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1838:
> 
>> 1836:   {
>> 1837:     ThreadInVMfromJava tiv(thread);
>> 1838:     state = get_jvmti_thread_state(thread);
> 
> The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else.

Thank you, Patricio! Good catch and suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2276043185

From ihse at openjdk.org  Thu Aug 14 09:42:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:42:16 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <oO0w2mjzbdgtkBcmvrBsHQN_MCxTKZR6PVWZUt2JTRQ=.3e5d7937-ed6a-4306-804c-10f73bcb3bd8@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
 <oO0w2mjzbdgtkBcmvrBsHQN_MCxTKZR6PVWZUt2JTRQ=.3e5d7937-ed6a-4306-804c-10f73bcb3bd8@github.com>
Message-ID: <Xr9N-eZR6lWVA4Oxw6RVLY-xpry6Cb-wFyKHxUuUaqI=.0d4d7aac-b6c9-492b-aa26-f34319467a9d@github.com>

On Mon, 11 Aug 2025 19:32:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Thank you feedback, I explained the usage of
> JTREG_JVMTI_STRESS_AGENT
> and applied your changes.

I can't see any updates to this PR? Did you forget to push your commits?

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3187804873

From sjohanss at openjdk.org  Thu Aug 14 11:30:18 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 14 Aug 2025 11:30:18 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
Message-ID: <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>

On Thu, 14 Aug 2025 07:49:26 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Albert
>
> src/hotspot/os/linux/os_linux.cpp line 4953:
> 
>> 4951:       // to detach itself from the VM - which should result in ESRCH.
>> 4952:       assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
>> 4953:       log_warning(os)("Could not sample thread CPU time (return code %d)", rc);
> 
> Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal?
> 
> The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output.
> 
> The same goes for the other warnings below.

Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276356967

From ayang at openjdk.org  Thu Aug 14 12:22:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 14 Aug 2025 12:22:13 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
Message-ID: <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>

On Thu, 14 Aug 2025 11:27:10 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 4953:
>> 
>>> 4951:       // to detach itself from the VM - which should result in ESRCH.
>>> 4952:       assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
>>> 4953:       log_warning(os)("Could not sample thread CPU time (return code %d)", rc);
>> 
>> Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal?
>> 
>> The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output.
>> 
>> The same goes for the other warnings below.
>
> Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings.

> ... it might happen from time to time without it being a very big deal?

My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276473605

From duke at openjdk.org  Thu Aug 14 13:11:12 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 14 Aug 2025 13:11:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
Message-ID: <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>

On Thu, 14 Aug 2025 12:19:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings.
>
>> ... it might happen from time to time without it being a very big deal?
> 
> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.

I don't sample GC threads that have terminated, so I would prefer not having the warning as well, as it would not fail unless the machine is in a bad state and then we would have larger issues at hand anyways?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276583734

From duke at openjdk.org  Thu Aug 14 13:11:14 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 14 Aug 2025 13:11:14 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <ScJxz_3oq2-HVbpfLTOAQBMRL89M3ntox_z2__y66sQ=.50bdac15-d68a-4fa1-8c9b-1a1793b05a82@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <ScJxz_3oq2-HVbpfLTOAQBMRL89M3ntox_z2__y66sQ=.50bdac15-d68a-4fa1-8c9b-1a1793b05a82@github.com>
Message-ID: <QCEOIpsD9Z1ehlJ3JC_I5YSLk1K3p4lzFO2VT8x0vU8=.18470345-9342-4944-bf1b-524ff75d3452@github.com>

On Tue, 12 Aug 2025 15:17:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Albert
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 610:
> 
>> 608: }
>> 609: 
>> 610: double percent_of(double component_cpu_time, double process_cpu_time) {
> 
> There is global function, `percent_of`. Can that be used directly?

Thanks! Certainly I misread your previous suggestion as a rename suggestion as I was not aware of that global function :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276587345

From duke at openjdk.org  Thu Aug 14 14:12:18 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 14 Aug 2025 14:12:18 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v6]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <ad5DY2SsqO7vgu0f6q_eiabwSPRi2fhN_RV3GhcZTEY=.50c248b2-0834-4461-a136-972953578bc5@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

 - Minor improvements and fixes per @kstefanj suggestions
 - use percent_of from globalDefinitions.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/143fcacb..ddab1f0b

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

  Stats: 118 lines in 4 files changed: 60 ins; 57 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

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

From duke at openjdk.org  Thu Aug 14 14:12:21 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 14 Aug 2025 14:12:21 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
Message-ID: <Yxmr8aoGP6WDPBhO0GjM-T1wafn30W-8K083ylmGDB8=.1f3f0998-3734-482f-a37f-0f7d4d085a0a@github.com>

On Thu, 14 Aug 2025 08:02:45 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Albert
>
> Thanks for looking at this and improving the CPU tracking and making it easily accessible. 
> 
> Overall I think the change looks good, just a few comments/questions.

Thanks for the review @kstefanj! I've pushed a patch reflecting your suggestions, but saved removal of log_warning until we have a consensus on a path forward.

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

PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3188595880

From sspitsyn at openjdk.org  Thu Aug 14 15:01:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Aug 2025 15:01:11 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v4]
In-Reply-To: <pzpPPoh1_-WEiv2MTckxvhzPnB7462KIBWf9KuXOBmU=.acad384a-0d46-4d6f-a687-2fd2d903cdff@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <JFtr3pOjDnihBw7pmCv_NkbY74iB4S6bJw26iU49yIg=.87e555d7-700d-4c4b-8c71-6ec739d9a8b8@github.com>
 <NVQtYP-t8QteXyeudM64_IVtJ0GDw7EkuNdy_Dz915M=.ff178d38-1978-4176-a59b-f46fae169ab3@github.com>
 <pzpPPoh1_-WEiv2MTckxvhzPnB7462KIBWf9KuXOBmU=.acad384a-0d46-4d6f-a687-2fd2d903cdff@github.com>
Message-ID: <lYM7hdMJqfjKYRkX2clxA6Zkql9vrP1KEmQyFFjBrUM=.7544f3d2-ee78-4178-b895-0bd863f224fd@github.com>

On Thu, 14 Aug 2025 09:15:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiExport.cpp line 1838:
>> 
>>> 1836:   {
>>> 1837:     ThreadInVMfromJava tiv(thread);
>>> 1838:     state = get_jvmti_thread_state(thread);
>> 
>> The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else.
>
> Thank you, Patricio! Good catch and suggestion.

This can be kind of intrusive, something like below (without changes from Leonid):

@@ -1830,6 +1830,16 @@ void JvmtiExport::post_method_entry(JavaThread *thread, Method* method, frame cu
 void JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) {
   HandleMark hm(thread);
   methodHandle mh(thread, method);
+  Handle result;
+  jvalue value;
+  oop oop_result;
+  BasicType type = current_frame.interpreter_frame_result(&oop_result, &value);
+
+  value.j = 0L;
+  if (is_reference_type(type)) {
+    result = Handle(thread, oop_result);
+    value.l = JNIHandles::make_local(thread, result());
+  }
 
   JvmtiThreadState *state = get_jvmti_thread_state(thread);
 
@@ -1841,21 +1851,15 @@ void JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame cur
   // return a flag when a method terminates by throwing an exception
   // i.e. if an exception is thrown and it's not caught by the current method
   bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();
-  Handle result;
-  jvalue value;
-  value.j = 0L;
 
   if (state->is_enabled(JVMTI_EVENT_METHOD_EXIT)) {
     // if the method hasn't been popped because of an exception then we populate
     // the return_value parameter for the callback. At this point we only have
     // the address of a "raw result" and we just call into the interpreter to
     // convert this into a jvalue.
-    if (!exception_exit) {
-      oop oop_result;
-      BasicType type = current_frame.interpreter_frame_result(&oop_result, &value);
+    if (exception_exit) {
       if (is_reference_type(type)) {
-        result = Handle(thread, oop_result);
-        value.l = JNIHandles::make_local(thread, result());
+        value.j = 0L;
       }
     }
   }

Not sure yet how to make it simpler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2276882958

From lmesnik at openjdk.org  Thu Aug 14 17:57:47 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Aug 2025 17:57:47 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v4]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <p87dbEDMlfYDTLMYTLnZt_zAnBU-ced1UXe74cj8JKs=.6c12e32f-6fe1-432a-8987-0adab8debde4@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:

 - removed space
 - removed wrong commit.
 - renamed functions, removed incorrect comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/49c2a67d..360db5d9

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

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

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

From lmesnik at openjdk.org  Thu Aug 14 17:59:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Aug 2025 17:59:13 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v4]
In-Reply-To: <NVQtYP-t8QteXyeudM64_IVtJ0GDw7EkuNdy_Dz915M=.ff178d38-1978-4176-a59b-f46fae169ab3@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <JFtr3pOjDnihBw7pmCv_NkbY74iB4S6bJw26iU49yIg=.87e555d7-700d-4c4b-8c71-6ec739d9a8b8@github.com>
 <NVQtYP-t8QteXyeudM64_IVtJ0GDw7EkuNdy_Dz915M=.ff178d38-1978-4176-a59b-f46fae169ab3@github.com>
Message-ID: <VKHET1Eo2dEleX-oASCrsa9vMtDS5LfDKR5tRwxrNFQ=.2fdad542-542e-457b-80b9-fd7d9219db0f@github.com>

On Thu, 14 Aug 2025 00:01:29 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:
>> 
>>  - added _
>>  - wong phase
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1838:
> 
>> 1836:   {
>> 1837:     ThreadInVMfromJava tiv(thread);
>> 1838:     state = get_jvmti_thread_state(thread);
> 
> The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else.

Thank you @pchilano and @sspitsyn for finding and explaining the issue.
I need some more time to understand how to better correctly preserve the result oop in post_method_exit before we can starting read jvmti_state.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2277367830

From dnsimon at openjdk.org  Thu Aug 14 19:33:15 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Aug 2025 19:33:15 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
Message-ID: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>

On Wed, 13 Aug 2025 14:22:08 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:
> 
>   After suggestions from Erik and Andrey

> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

Would you mind also running tier9 to avoid surprises there.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3189640422

From lmesnik at openjdk.org  Thu Aug 14 19:44:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Aug 2025 19:44:59 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v5]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:

 - Apply suggestions from code review
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - Update test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - Update test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/360db5d9..d45c0701

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

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

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

From lmesnik at openjdk.org  Thu Aug 14 19:44:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Aug 2025 19:44:59 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v4]
In-Reply-To: <p87dbEDMlfYDTLMYTLnZt_zAnBU-ced1UXe74cj8JKs=.6c12e32f-6fe1-432a-8987-0adab8debde4@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <p87dbEDMlfYDTLMYTLnZt_zAnBU-ced1UXe74cj8JKs=.6c12e32f-6fe1-432a-8987-0adab8debde4@github.com>
Message-ID: <DBWB8LCZreAsAVGXvbuBbO8_K0UL_dZv-48sU8aFLHM=.20f0478f-bb61-46b1-b2c3-b81800b44839@github.com>

On Thu, 14 Aug 2025 17:57:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - removed space
>  - removed wrong commit.
>  - renamed functions, removed incorrect comments

Sorry, I just forgot to "apply" your comments, thanks for reminding!

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3189671622

From erikj at openjdk.org  Thu Aug 14 19:52:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Aug 2025 19:52:12 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v5]
In-Reply-To: <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>
Message-ID: <u4MMn-V6jCc-EnD3MhNSni375i5aigEojiLj1Mcoiis=.dca4effa-501d-4933-a6ff-ab29c740ed64@github.com>

On Thu, 14 Aug 2025 19:44:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - Update test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - Update test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

Makefile changes look good now.

I think this new option should be documented in testing.md/html.

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

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3121925674

From ihse at openjdk.org  Thu Aug 14 21:18:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 21:18:13 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v5]
In-Reply-To: <u4MMn-V6jCc-EnD3MhNSni375i5aigEojiLj1Mcoiis=.dca4effa-501d-4933-a6ff-ab29c740ed64@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>
 <u4MMn-V6jCc-EnD3MhNSni375i5aigEojiLj1Mcoiis=.dca4effa-501d-4933-a6ff-ab29c740ed64@github.com>
Message-ID: <qlNebN3xJFHgfbDPIzK702OqMlpmqtdq6vzfY_5I6hQ=.4c0b19cb-5cfe-4d17-8f57-fbd4749d6969@github.com>

On Thu, 14 Aug 2025 19:49:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think this new option should be documented in testing.md/html.

Yes, I agree. I tried to ask for this above. @lmesnik When you have updated the markdown file, run `make update-build-docs` to generate the html version.

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3189894607

From lmesnik at openjdk.org  Fri Aug 15 04:33:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 04:33:59 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

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

  add documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/d45c0701..514ed252

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

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

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

From lmesnik at openjdk.org  Fri Aug 15 04:37:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 04:37:12 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
Message-ID: <3Wv7WQnb0uRdX37iZ3RDXljs6cncyI8b6mTujVfp0A4=.5859b0a5-0dac-4eaa-831e-89c420393153@github.com>

On Fri, 15 Aug 2025 04:33:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documentation

Sorry, I just didn't have time today. I updated .md and regenerated .html using `make update-build-docs` command.

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3190585133

From sjohanss at openjdk.org  Fri Aug 15 07:00:12 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 15 Aug 2025 07:00:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
 <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
Message-ID: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>

On Thu, 14 Aug 2025 13:07:07 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>>> ... it might happen from time to time without it being a very big deal?
>> 
>> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.
>
> I don't sample GC threads that have terminated, so I would prefer not having the warning as well, as it would not fail unless the machine is in a bad state and then we would have larger issues at hand anyways?

> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.

Sure, that could be helpful. I don't think it should be a warning on the OS API though. Looking at the code a log message like that could be added to `CPUTimeThreadClosure::do_thread(...)`. To me it would be enough to have that on `log_info(cpu)` possibly even on debug-level. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278420082

From sspitsyn at openjdk.org  Fri Aug 15 07:03:15 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 15 Aug 2025 07:03:15 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
Message-ID: <4l03LqVrTEjF0hwX9gcoaopc4ADypXFmUCNYFht2Fp8=.3d2946a8-02e6-40fb-b434-59c394cc187f@github.com>

On Fri, 15 Aug 2025 04:33:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documentation

Thank you for the updates in the stress agent `.cpp` file!
This looks okay to me modulo potential doc update.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3123114291

From ayang at openjdk.org  Fri Aug 15 08:08:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 15 Aug 2025 08:08:13 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
 <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
 <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>
Message-ID: <YHjBFys5Pj9ZZNro4gMk-EHI6fFbHPnXgwmkvdsaQ2w=.4877c69c-805e-4b85-9b62-3153f3064c91@github.com>

On Fri, 15 Aug 2025 06:57:04 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>  I don't think it should be a warning on the OS API though.

Agree. At this level, returning `-1` already indicates the error -- callers should/can check the return-value and act on it.

> ... could be added to CPUTimeThreadClosure::do_thread(...)

There are dozens of callers though; `CPUTimeThreadClosure` is just one. For this particular patch, I think emitting some msg/warning somewhere inside `static void log_cpu_time` may be enough. WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278499043

From sjohanss at openjdk.org  Fri Aug 15 08:27:12 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 15 Aug 2025 08:27:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <YHjBFys5Pj9ZZNro4gMk-EHI6fFbHPnXgwmkvdsaQ2w=.4877c69c-805e-4b85-9b62-3153f3064c91@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
 <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
 <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>
 <YHjBFys5Pj9ZZNro4gMk-EHI6fFbHPnXgwmkvdsaQ2w=.4877c69c-805e-4b85-9b62-3153f3064c91@github.com>
Message-ID: <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com>

On Fri, 15 Aug 2025 08:05:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.
>> 
>> Sure, that could be helpful. I don't think it should be a warning on the OS API though. Looking at the code a log message like that could be added to `CPUTimeThreadClosure::do_thread(...)`. To me it would be enough to have that on `log_info(cpu)` possibly even on debug-level. What do you think?
>
>>  I don't think it should be a warning on the OS API though.
> 
> Agree. At this level, returning `-1` already indicates the error -- callers should/can check the return-value and act on it.
> 
>> ... could be added to CPUTimeThreadClosure::do_thread(...)
> 
> There are dozens of callers though; `CPUTimeThreadClosure` is just one. For this particular patch, I think emitting some msg/warning somewhere inside `static void log_cpu_time` may be enough. WDYT?

I don't have super strong opinion here, but to be able to add some message in `log_cpu_time` we would need to add logic to the `CPUTimeThreadClosure` to know if something went wrong or am I missing what you are suggesting? 

And that message would not know what thread we failed to measure, but the closure have that information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278524140

From ihse at openjdk.org  Fri Aug 15 08:41:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Aug 2025 08:41:16 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
Message-ID: <mOOh-94SQTg7Wv_BuNch9Nww8heX1c0fisU3YtDFHr8=.cd9ad424-80b3-42d5-8df7-d2701d5bc096@github.com>

On Fri, 15 Aug 2025 04:33:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documentation

LGTM now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3123261422

From ayang at openjdk.org  Fri Aug 15 08:45:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 15 Aug 2025 08:45:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
 <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
 <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>
 <YHjBFys5Pj9ZZNro4gMk-EHI6fFbHPnXgwmkvdsaQ2w=.4877c69c-805e-4b85-9b62-3153f3064c91@github.com>
 <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com>
Message-ID: <rlwaFxexzC5GYcLWSa0yk7ILusI3TOSGcClBybgB2B4=.e1cf3f57-0355-4b8d-89c7-4fff186aed23@github.com>

On Fri, 15 Aug 2025 08:24:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> ... am I missing what you are suggesting?

No. I think we are on the same page; I was more focusing on where the msg/warning will be, since this thread started with "Do we really want add a warning here?"

> And that message would not know what thread we failed to measure, but the closure have that information.

True; need to collect these info so that the printed msg/warning shows which thread(s) encountered a failure, if any.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278547920

From ihse at openjdk.org  Fri Aug 15 08:48:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Aug 2025 08:48:14 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
Message-ID: <QCO91hIQ9kjsa4Rz0UWogznMEJY294fuUE841MfK4nM=.09050211-f06e-48a0-90ba-c4fbde1b9aaa@github.com>

On Fri, 15 Aug 2025 04:33:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documentation

Actually, GHA testing fails with an error in libJvmtiStressAgent.cpp. Please investigate.

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

Changes requested by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3123276665

From lkorinth at openjdk.org  Fri Aug 15 11:43:33 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:43:33 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@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:

  added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/dbe42964..8fa40e7d

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

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 lkorinth at openjdk.org  Fri Aug 15 11:59:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:59:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <iWlp9Azqc_MsGBnk-PK8OYZqpcnhSASRJmnz8IgzTQI=.965cedce-3e5a-40e5-9e86-9b1f5c2d2021@github.com>

On Fri, 15 Aug 2025 11:43:33 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:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Added three new `/timeout=480` after the last run.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3191343090

From syan at openjdk.org  Fri Aug 15 14:08:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 15 Aug 2025 14:08:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>

On Fri, 15 Aug 2025 11:43:33 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:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

make/RunTests.gmk line 940:

> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1

Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

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

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

From lmesnik at openjdk.org  Fri Aug 15 15:05:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 15:05:02 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v7]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

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

  initialization of array fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/514ed252..0dc79e03

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

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

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

From erikj at openjdk.org  Fri Aug 15 16:57:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 15 Aug 2025 16:57:15 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v7]
In-Reply-To: <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
Message-ID: <z7cQSOF6vhL_tde4GXXjKzZWygdmCvZVwKMcBW75pdQ=.f9ebe983-39ae-4a8a-b4b8-cd17167482b3@github.com>

On Fri, 15 Aug 2025 15:05:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initialization of array fixed

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3124547850

From lmesnik at openjdk.org  Fri Aug 15 17:36:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 17:36:12 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v7]
In-Reply-To: <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
Message-ID: <D6kWOak-Gr4XrgnBxrT7fpjHU8DXSSvJROqP-fpKC00=.1355a4d5-120d-4ded-8cbd-341adc1e0d9d@github.com>

On Fri, 15 Aug 2025 15:05:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initialization of array fixed

Thanks! I fixed cpp issue. Interesting that our builds worked before. Re-run tier1 to verify builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3192267556

From ihse at openjdk.org  Fri Aug 15 22:39:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Aug 2025 22:39:11 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v7]
In-Reply-To: <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
Message-ID: <OCwmQQK3q00bdUA2zbyCNQdwjkZ2OtuqWbH41uRgiMg=.f6e44820-d9a7-42ab-9f36-3e65d2f7cef6@github.com>

On Fri, 15 Aug 2025 15:05:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initialization of array fixed

LGTMN.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3125301189

From lmesnik at openjdk.org  Fri Aug 15 22:48:20 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 22:48:20 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v5]
In-Reply-To: <qlNebN3xJFHgfbDPIzK702OqMlpmqtdq6vzfY_5I6hQ=.4c0b19cb-5cfe-4d17-8f57-fbd4749d6969@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>
 <u4MMn-V6jCc-EnD3MhNSni375i5aigEojiLj1Mcoiis=.dca4effa-501d-4933-a6ff-ab29c740ed64@github.com>
 <qlNebN3xJFHgfbDPIzK702OqMlpmqtdq6vzfY_5I6hQ=.4c0b19cb-5cfe-4d17-8f57-fbd4749d6969@github.com>
Message-ID: <glVYs39XO2XVAVi8XwZfIwwtqjkM__LWVUlNPYgle6k=.32b9a0e7-271d-45c9-8dab-5924a68218c5@github.com>

On Thu, 14 Aug 2025 21:15:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Makefile changes look good now.
>> 
>> I think this new option should be documented in testing.md/html.
>
>> I think this new option should be documented in testing.md/html.
> 
> Yes, I agree. I tried to ask for this above. @lmesnik When you have updated the markdown file, run `make update-build-docs` to generate the html version.

@magicus , @erikj79,  @sspitsyn Thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3192942142

From lmesnik at openjdk.org  Fri Aug 15 22:48:22 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 22:48:22 GMT
Subject: Integrated: 8364973: Add JVMTI stress testing mode
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <454Ns3j_zbqBf1aNJiYQyTBmat468MpZ30TwMz3oDQY=.1d612ec3-8190-4618-b76a-f012601244c8@github.com>

On Thu, 17 Jul 2025 02:39:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

This pull request has now been integrated.

Changeset: a70521c6
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a70521c62e0841895d71cce2c872bd12f1183e33
Stats:     1199 lines in 10 files changed: 1192 ins; 3 del; 4 mod

8364973: Add JVMTI stress testing mode

Reviewed-by: erikj, ihse, sspitsyn

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

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

From yasuenag at gmail.com  Sat Aug 16 14:44:26 2025
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Sat, 16 Aug 2025 23:44:26 +0900
Subject: Send attach request even though SigCgt is not set
Message-ID: <7bb26058-8481-47f0-ba00-01cb253bb554@gmail.com>

Hi all,

I'm working on JDK-8365633, then I want to attach to the process via 
jcmd on WSL 1 (to test hybrid CPU on Linux on Windows), however I couldn't.
I want to add a system property like an expert mode to force sending 
signal. What do you think?

I investigated 
src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java , 
then I found following code:

```
 ??????? for (var line : Files.readAllLines(procPid.resolve("status"))) {

 ??????????? if (!line.startsWith("Sig")) continue; // to speed things 
up ... avoids the matcher/RE invocation...

 ??????????? final var m = SIGNAL_MASK_PATTERN.matcher(line);

 ??????????? if (!m.matches()) continue;

 ??????????? var?????? sigmask = m.group(MASK);
 ??????????? final var slen??? = sigmask.length();

 ??????????? sigmask = sigmask.substring(slen / 2 , slen); // only 
really interested in the non r/t signals ...

 ??????????? final var sigquit = (Long.valueOf(sigmask, 16) & SIGQUIT) 
!= 0L;

 ??????????? switch (m.group(FIELD)) {
 ??????????????? case "SigBlk": { quitBlk = sigquit; readBlk = true; 
break; }
 ??????????????? case "SigIgn": { quitIgn = sigquit; readIgn = true; 
break; }
 ??????????????? case "SigCgt": { quitCgt = sigquit; readCgt = true; 
break; }
 ??????????? }

 ??????????? if (readBlk && readIgn && readCgt) break;
 ??????? }

 ??????? final boolean? okToSendQuit = (!quitIgn && quitCgt); // ignore 
blocked as it may be temporary ...

 ??????? if (okToSendQuit) {
 ??????????? sendQuitTo(pid);
```

This code has been introduced in JDK-8342449.
I agree with not to send signal if it is not accepted by the target, 
however I think it is better to add an option to force the signal to be 
sent.

It seems to be a bug on WSL 1 because it does not seems to cover all of 
Linux signal implementation e.g. 
https://github.com/microsoft/WSL/issues/1880 . So it should be fixed in 
WSL, however it should be available like an expert mode on Attach API 
implementation - I guess it would be added as a system property.

I will file this to JBS and create PR if this proposal is accepted.
I want to hear your comments before that work because I understand it is 
not a bug on Java.
Any comments are welcome.


Thanks,

Yasumasa