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


From lkorinth at openjdk.org  Mon Aug 18 09:10:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:10:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
Message-ID: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>

On Fri, 15 Aug 2025 14:05:49 GMT, SendaoYan <syan at openjdk.org> wrote:

>> 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()

It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:18:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:18:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
Message-ID: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>

On Mon, 18 Aug 2025 09:07:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> 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()
>
> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

It is also something that can be changed later, in a follow up fix.

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
 <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
Message-ID: <3l5I9q7S4O_0gH6mvxy3P21f1JxqcQKNsnBTN7rWhmc=.ddcf4337-dc6e-493d-ae07-5bd4affb9321@github.com>

On Thu, 14 Aug 2025 19:30:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

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

I had problems doing this, and I just want to say that I have not run tier9 (I have talked to Douglas off-list).

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:43:14 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:43:14 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: <9GMJWT-CNwqDVALuPdRR9EDs5G1c2jUr3y887qw2_EU=.1a7347a2-d1e5-427d-aeda-6924e2db39ba@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

If there are no mayor objections, I will update the copyrights before I leave work today.

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

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

From dfuchs at openjdk.org  Mon Aug 18 11:38:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 11:38:14 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: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@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

Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:


	java/net/httpclient/CancelledResponse.java
	java/net/httpclient/whitebox/FlowTestDriver.java


The	first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

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

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

From rriggs at openjdk.org  Mon Aug 18 13:15:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 13:15:11 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: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@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

Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings.  The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

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

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

From duke at openjdk.org  Mon Aug 18 13:40:21 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 18 Aug 2025 13:40:21 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v7]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <WNnTyj15PqUHRsB8v_cOi_Qx7FoYB-8T6jQAkePI27w=.fafb35b4-981d-43a2-9f1b-3a0652281a3a@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:

  Implement optional error handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/ddab1f0b..8fe49703

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

  Stats: 38 lines in 6 files changed: 29 ins; 8 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  Mon Aug 18 13:40:22 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 18 Aug 2025 13:40:22 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v6]
In-Reply-To: <ad5DY2SsqO7vgu0f6q_eiabwSPRi2fhN_RV3GhcZTEY=.50c248b2-0834-4461-a136-972953578bc5@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <ad5DY2SsqO7vgu0f6q_eiabwSPRi2fhN_RV3GhcZTEY=.50c248b2-0834-4461-a136-972953578bc5@github.com>
Message-ID: <N88QM9NlAP3Qe2xrKak5mJWyCjLJC6mV6o0kaGSfmhE=.6a93ada7-729b-4163-863b-36561ff0df18@github.com>

On Thu, 14 Aug 2025 14:12:18 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 two additional commits since the last revision:
> 
>  - Minor improvements and fixes per @kstefanj suggestions
>  - use percent_of from globalDefinitions.hpp

As per our offline discussion I implemented an optional error handling mechanism to allow users of this framework decide if they care or not.

If errors are found we print something like this in the end:

[0.569s][info][cpu] === CPU time Statistics =============================================================
[0.569s][info][cpu] WARNING: CPU time sampling reported errors, numbers may be unreliable
[0.569s][info][cpu]                                                                             CPUs
[0.569s][info][cpu]                                                                s       %  utilized
[0.569s][info][cpu]    Process
[0.569s][info][cpu]      Total                                                2.2719  100.00       4.0
[0.569s][info][cpu]      VM Thread                                            0.0031    0.14       0.0
[0.569s][info][cpu]      Garbage Collection                                   0.0146    0.64       0.0
[0.569s][info][cpu]        GC Threads                                         0.0141    0.62       0.0
[0.569s][info][cpu]        VM Thread                                          0.0006    0.03       0.0
[0.569s][info][cpu] =====================================================================================

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

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

From duke at openjdk.org  Mon Aug 18 13:56:03 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 18 Aug 2025 13:56:03 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v8]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <lYgyWIUfo-YSxjDQLSKNdUwIS2SW5VXQTJovyj89qt0=.d8c09b42-9576-49b3-b1c4-984bd3bb7f51@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
 - Minor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/8fe49703..9aa28717

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

  Stats: 7 lines in 2 files changed: 0 ins; 4 del; 3 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  Mon Aug 18 14:02:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 18 Aug 2025 14:02:48 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v9]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@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:

  Fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/9aa28717..afbff568

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

  Stats: 36 lines in 2 files changed: 2 ins; 1 del; 33 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 lkorinth at openjdk.org  Mon Aug 18 14:34:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 14:34:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
Message-ID: <lSUzoh2lhdmeEPYY2eAAGIycS8QSm5_9BLFy7FgOfFw=.f7a8acc4-ead5-4625-9d3c-83a345212193@github.com>

On Mon, 18 Aug 2025 13:12:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings. The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

Noted. I did it so reviewers could se the change "as a whole". Feel free to review a part of the change!

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

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

From lmesnik at openjdk.org  Mon Aug 18 15:01:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 18 Aug 2025 15:01: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: <O_WRSR2Q7KM1CWMYPxfXyFQI3lU9AjTOklWNVYAxvUk=.387e933f-0eed-43d8-a2eb-dbe2dd98cc75@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

Thank you for fixing this! I think the changes are good.

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

Marked as reviewed by lmesnik (Reviewer).

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

From larry.cable at oracle.com  Mon Aug 18 15:46:25 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Mon, 18 Aug 2025 08:46:25 -0700
Subject: Send attach request even though SigCgt is not set
In-Reply-To: <7bb26058-8481-47f0-ba00-01cb253bb554@gmail.com>
References: <7bb26058-8481-47f0-ba00-01cb253bb554@gmail.com>
Message-ID: <27020385-670d-4892-b7e2-fd51b63441e2@oracle.com>

I'm personally extremely disinclined to add an 'expert' property to 
'fix' a bug in MSFT WSL's emulation of Linux signals and /proc
semantics.

the code you refer to was added to explicitly avoid the terminal issue 
of a jcmd sending SIGQUIT to a JVM unprepared to handle it

since this is is apparently fixed in WSL2 and a bug is filed on WSL1 I 
recommend we wait until MSFT fix their code and not
work around it with a mode.

Rgds

- Larry

On 8/16/25 7:44 AM, Yasumasa Suenaga wrote:
> 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
>


From lkorinth at openjdk.org  Mon Aug 18 16:34:21 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:21 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@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 suggestion from Daniel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/8fa40e7d..286a2cc6

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

  Stats: 3 lines in 2 files 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  Mon Aug 18 16:34:22 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:22 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
Message-ID: <KNNxBq11P7lT_D16Mzwx-_VHkNITiw5wQbuYCf58yQI=.cdcf7871-b20c-4e44-b10e-c6108e647afb@github.com>

On Mon, 18 Aug 2025 11:34:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:
> 
> ```
> 	java/net/httpclient/CancelledResponse.java
> 	java/net/httpclient/whitebox/FlowTestDriver.java
> ```
> 
> The first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

Fixed! Thanks for helping!

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

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

From dfuchs at openjdk.org  Mon Aug 18 16:46:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 16:46:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <a3CwlSQwHYj_F3fC30zoiDhXf9G-cn5xK8ZwVFmxBd0=.afdaf352-e494-4bc6-adf2-dc5afa0dd4b9@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

Thanks! Changes to JNDI / net / httpclient LGTM.

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

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

From syan at openjdk.org  Tue Aug 19 03:34:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 03:34:47 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
Message-ID: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>

On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.
>
> It is also something that can be changed later, in a follow up fix.

Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds too long and it's unacceptable.

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

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

From dholmes at openjdk.org  Tue Aug 19 05:25:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:25:40 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
Message-ID: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>

On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> It is also something that can be changed later, in a follow up fix.
>
> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.

> It is unclear to me if the author meant this to be 2.5 more than normal or 10 more than JTREG default, or a multiplier that seems to work. 

What matters is that the actual timeout, in seconds, remains unchanged, so please address this. Timeouts that are excessively long waste machine resources.

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

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

From dholmes at openjdk.org  Tue Aug 19 05:49:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:49:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

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

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

From lmesnik at openjdk.org  Tue Aug 19 05:54:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Aug 2025 05:54:13 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <POtW6Q5sBINfz3VlSkAj_802AFvVFwtsyui5s_nXcCg=.5d30973a-6a23-4b73-b430-b06eddda99bc@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - The oop preservation and exception handling has been fixed.
 - Test added.
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192
 - added _
 - wong phase
 - fixed name
 - simplified after feedback
 - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state

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

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

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

  Stats: 14918 lines in 409 files changed: 8347 ins; 4914 del; 1657 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  Tue Aug 19 06:01:42 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Aug 2025 06:01:42 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v4]
In-Reply-To: <VKHET1Eo2dEleX-oASCrsa9vMtDS5LfDKR5tRwxrNFQ=.2fdad542-542e-457b-80b9-fd7d9219db0f@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>
 <VKHET1Eo2dEleX-oASCrsa9vMtDS5LfDKR5tRwxrNFQ=.2fdad542-542e-457b-80b9-fd7d9219db0f@github.com>
Message-ID: <I3TXvJNrabA4Avz-8Bt2Tkjtqs6AaCIGr1_eDkyjUJc=.e0c47825-bd0a-4550-980b-132fed958b71@github.com>

On Thu, 14 Aug 2025 17:56:49 GMT, Leonid Mesnik <lmesnik 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 @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.

I reviewed the logic and it seems, that `exception_exit` is not needed here. The 'post_method_exit' is called only when method exits normally. The `notice_unwind_due_to_exception`happens if method exit because of exception.
I added a regression test that demonstrate the problem. The upcall method is not handled correctly before this fix. 
Also, it means that result should be always valid and it is always needed to handle result. There is no way to avoid safepoints in this method even MethodExit is not enabled.
However, JNIHandle is needed for events only and shouldn't be created until events are enabled.

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

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

From dholmes at openjdk.org  Tue Aug 19 06:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 06:07:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
Message-ID: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>

On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
>> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.
>
> DELETED - I confused the timeout with the timeout-factor. New comment below.

No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 

However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

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

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

From syan at openjdk.org  Tue Aug 19 06:40:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 06:40:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
Message-ID: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>

On Tue, 19 Aug 2025 06:04:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DELETED - I confused the timeout with the timeout-factor. New comment below.
>
> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
> 
> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.

The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

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

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

From sjohanss at openjdk.org  Tue Aug 19 08:19:42 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 19 Aug 2025 08:19:42 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v9]
In-Reply-To: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com>
Message-ID: <Bu03eC719kfHl3voUWlvrisJferkSTjgHzBcB5tO7h8=.12d14aaa-9b47-4063-bc11-8c4482d5353a@github.com>

On Mon, 18 Aug 2025 14:02:48 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:
> 
>   Fix indentation

Just some minor things that you can fix before integrating. Otherwise I think this looks good.

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

> 57: #include "runtime/threadSMR.hpp"
> 58: #include "runtime/vmThread.hpp"
> 59: #include "services/cpuTimeUsage.hpp"

Can be removed now.

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

> 432:   void print_relative_to_gc(GCWhen::Type when) const;
> 433: 
> 434:   void log_cpu_time() const;

This has moved to `Universe` and can be removed.

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

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3131175838
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284454451
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284450710

From duke at openjdk.org  Tue Aug 19 08:42:15 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 08:42:15 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@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:

  Remove unused

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/afbff568..79a3323a

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

  Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 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 lkorinth at openjdk.org  Tue Aug 19 09:02:36 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:02:36 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
Message-ID: <uOH12UfZUHixcxSAx8lP66zvzxKr50yUj8x4_x22Su0=.31769f01-81c4-48b0-9050-f642c562deb5@github.com>

On Tue, 19 Aug 2025 05:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

Thanks David! And as you said, a few more adjustments will probably be needed when we have run this for a while.

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

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

From lkorinth at openjdk.org  Tue Aug 19 09:19:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:19:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <BM1P_203-vMLbBYxbzigREy0NuHWoZqfgQvmGV0SH7I=.bf66ee89-19a9-4212-b800-08e7c835f4de@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

I do not think 4x longer timeouts for `-Xcomp` is unreasonable. I also do not want to make this huge change even bigger. If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.

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

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

From ayang at openjdk.org  Tue Aug 19 11:35:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 19 Aug 2025 11:35:39 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
Message-ID: <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>

On Tue, 19 Aug 2025 08:42:15 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:
> 
>   Remove unused

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

> 623:       ClassLoaderDataGraph::print_on(&ls_trace);
> 624:     }
> 625:   }

I don't think this code movement should be done -- this calls back to `Universe` and CLDG printing is not necessarily tired to heap.

src/hotspot/share/services/cpuTimeUsage.cpp line 43:

> 41: public:
> 42:   virtual void do_thread(Thread* thread) {
> 43:     jlong cpu_time = os::thread_cpu_time(thread);

I guess a wrapper for `thread_cpu_time` can be created to group error-handling logic together, for all uses in this file.


jlong thread_cpu_time_or_zero(thread) {
  jlong cpu_time = os::..
  if (cpu_time == -1) {
    // mark-error
    return 0;
  }
  return cpu_time;
}

src/hotspot/share/services/cpuTimeUsage.hpp line 47:

> 45:     static jlong gc_threads();
> 46:     static jlong vm_thread();
> 47:     static jlong stringdedup();

I feel the API surface contains some redundancy.

For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one.

The calculation of `total` should be done by users of this API, I believe, when/if total is desirable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284933253
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284962585
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284952784

From duke at openjdk.org  Tue Aug 19 14:30:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 14:30:48 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
Message-ID: <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>

On Tue, 19 Aug 2025 11:18:48 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:
>> 
>>   Remove unused
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 625:
> 
>> 623:       ClassLoaderDataGraph::print_on(&ls_trace);
>> 624:     }
>> 625:   }
> 
> I don't think this code movement should be done -- this calls back to `Universe` and CLDG printing is not necessarily tired to heap.

The motivation to move into `CollectedHeap::before_exit` is that now we finally have a specific method that is called for GC activites during exit so there is no need to conflate java.cpp with these tasks.

> this calls back to Universe

It called back to Universe in java.cpp too. Maybe you would want `Universe::print_on` to be refactored into CollectedHeap too? If that's the case maybe we should save that for a separate issue.

 > CLDG printing is not necessarily tired to heap

That could be so, but it is put under `gc+exit` tag. Are you suggesting that we should break this apart and do it under another tag?

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

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

From duke at openjdk.org  Tue Aug 19 14:48:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 14:48:43 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
Message-ID: <zZFaZy5nR-c_JfPOsuc6TBr4rNamvrjzfh9BRqyRjWI=.95005257-a9b6-403b-a94f-03ba5a8d70c2@github.com>

On Tue, 19 Aug 2025 11:27:53 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:
>> 
>>   Remove unused
>
> src/hotspot/share/services/cpuTimeUsage.hpp line 47:
> 
>> 45:     static jlong gc_threads();
>> 46:     static jlong vm_thread();
>> 47:     static jlong stringdedup();
> 
> I feel the API surface contains some redundancy.
> 
> For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one.
> 
> The calculation of `total` should be done by users of this API, I believe, when/if total is desirable.

The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it.

If you look at e.g. `WeakProcessor::CountingClosure`  the following is defined

  size_t dead() const { return _old_dead + _new_dead; }
  size_t new_dead() const { return _new_dead; }
  size_t total() const { return dead() + _live; }


so having such convenience method in hotspot is not unprecedented and I would prefer keeping it.

`statistics()` is a less important convenience method that can be removed.

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

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

From cjplummer at openjdk.org  Tue Aug 19 14:53:46 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 19 Aug 2025 14:53:46 GMT
Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT
 errors [v2]
In-Reply-To: <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com>
References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com>
 <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com>
Message-ID: <J9V1IMtMuTa0MPG8EkNDlZ_j6Vkp57hsAFFa4GYr9fo=.f345570d-1484-4231-b382-4d1411b48d81@github.com>

On Tue, 22 Jul 2025 06:11:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error.
>> 
>> (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX
>> 
>>   The implementation is unable to set the frame locals
>>   (e.g. the frame at depth is executing a native method).
>> 
>> However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this.
>> 
>> (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn:
>> 
>>   The implementation is unable to force the current frame to return
>>   (e.g. current frame is executing a native method).
>> 
>> However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this.
>> 
>> (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make workding more like JVMTI spec

Thanks for the reviews Alan, Alex, and Serguei!

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

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

From phh at openjdk.org  Tue Aug 19 15:03:21 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 19 Aug 2025 15:03:21 GMT
Subject: RFR: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
Message-ID: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>

The fix for [JDK-8279005](https://bugs.openjdk.org/browse/JDK-8279005) also fixed [JDK-8248691](https://bugs.openjdk.org/browse/JDK-8248691) and [JDK-8268211](https://bugs.openjdk.org/browse/JDK-8268211), which latter two are closed as dups. So, I've removed all jstatLineCountsX.sh from the ProblemList. I propose this patch is trivial.

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

Commit messages:
 - 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from ProblemList on linux-ppc64le and aix due to JDK-8248691

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

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

From eastigeevich at openjdk.org  Tue Aug 19 15:03:21 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 19 Aug 2025 15:03:21 GMT
Subject: RFR: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
In-Reply-To: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
References: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
Message-ID: <76Dga_-D94AVcITuaCnn0pV6Zk5A1MaOIuHvzeDl3R4=.fc9cff9e-b6aa-4ef3-ad1c-be3fd6eb3ffe@github.com>

On Tue, 19 Aug 2025 14:18:15 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> The fix for [JDK-8279005](https://bugs.openjdk.org/browse/JDK-8279005) also fixed [JDK-8248691](https://bugs.openjdk.org/browse/JDK-8248691) and [JDK-8268211](https://bugs.openjdk.org/browse/JDK-8268211), which latter two are closed as dups. So, I've removed all jstatLineCountsX.sh from the ProblemList. I propose this patch is trivial.

lgtm

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

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26844#pullrequestreview-3132727190

From ayang at openjdk.org  Tue Aug 19 15:03:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 19 Aug 2025 15:03:42 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
 <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
Message-ID: <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>

On Tue, 19 Aug 2025 14:27:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> now we finally have a specific method that is called for GC activites...

Then, it should be in `Universe::before_exit`, not inside heap.

>> src/hotspot/share/services/cpuTimeUsage.hpp line 47:
>> 
>>> 45:     static jlong gc_threads();
>>> 46:     static jlong vm_thread();
>>> 47:     static jlong stringdedup();
>> 
>> I feel the API surface contains some redundancy.
>> 
>> For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one.
>> 
>> The calculation of `total` should be done by users of this API, I believe, when/if total is desirable.
>
> The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it.
> 
> If you look at e.g. `WeakProcessor::CountingClosure`  the following is defined
> 
>   size_t dead() const { return _old_dead + _new_dead; }
>   size_t new_dead() const { return _new_dead; }
>   size_t total() const { return dead() + _live; }
> 
> 
> so having such convenience method in hotspot is not unprecedented and I would prefer keeping it.
> 
> `statistics()` is a less important convenience method that can be removed.

I think the smallest API would be `statisics()`, which returns all sub-components, and consumers of this API can calculate other derived metrics. YMMV.

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

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

From cjplummer at openjdk.org  Tue Aug 19 15:08:48 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 19 Aug 2025 15:08:48 GMT
Subject: Integrated: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and
 INVALID_SLOT errors
In-Reply-To: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com>
References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com>
Message-ID: <ScAC9Ym2-40LOU6J3tas9PWDsVj5NUpGOHk-7dVajr0=.0151927d-b124-4bbe-9956-87a537e2e218@github.com>

On Tue, 15 Jul 2025 22:50:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error.
> 
> (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX
> 
>   The implementation is unable to set the frame locals
>   (e.g. the frame at depth is executing a native method).
> 
> However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this.
> 
> (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn:
> 
>   The implementation is unable to force the current frame to return
>   (e.g. current frame is executing a native method).
> 
> However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this.
> 
> (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands.

This pull request has now been integrated.

Changeset: 4ed268ff
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ed268ff9aa6059221d76291c031b0fd29e20b95
Stats:     16 lines in 1 file changed: 2 ins; 5 del; 9 mod

8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors

Reviewed-by: sspitsyn, alanb, amenkov

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

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

From duke at openjdk.org  Tue Aug 19 15:12:40 2025
From: duke at openjdk.org (Elif Aslan)
Date: Tue, 19 Aug 2025 15:12:40 GMT
Subject: RFR: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
In-Reply-To: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
References: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
Message-ID: <nQVI9WqO120KbGih4_hEuo0Wb3fARP1fTnFWv8wMLuU=.93778e5d-1972-43ef-b8f3-baa42bfdcc7e@github.com>

On Tue, 19 Aug 2025 14:18:15 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> The fix for [JDK-8279005](https://bugs.openjdk.org/browse/JDK-8279005) also fixed [JDK-8248691](https://bugs.openjdk.org/browse/JDK-8248691) and [JDK-8268211](https://bugs.openjdk.org/browse/JDK-8268211), which latter two are closed as dups. So, I've removed all jstatLineCountsX.sh from the ProblemList. I propose this patch is trivial.

Marked as reviewed by elifaslan1 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/26844#pullrequestreview-3132773534

From simonis at openjdk.org  Tue Aug 19 15:18:37 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 19 Aug 2025 15:18:37 GMT
Subject: RFR: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
In-Reply-To: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
References: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
Message-ID: <4qidglHH5GBkTrOWg5RjvQHgvDFNU4z1VPbj9V3bTdo=.82952c1a-5ac6-4384-b7b0-3bee23e862d4@github.com>

On Tue, 19 Aug 2025 14:18:15 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> The fix for [JDK-8279005](https://bugs.openjdk.org/browse/JDK-8279005) also fixed [JDK-8248691](https://bugs.openjdk.org/browse/JDK-8248691) and [JDK-8268211](https://bugs.openjdk.org/browse/JDK-8268211), which latter two are closed as dups. So, I've removed all jstatLineCountsX.sh from the ProblemList. I propose this patch is trivial.

@MBaesken , @ArnoZeller can you please check if the test can be removed from the problem list on linux-ppc64le and AIX?

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

PR Comment: https://git.openjdk.org/jdk/pull/26844#issuecomment-3201178472

From duke at openjdk.org  Tue Aug 19 15:56:39 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 15:56:39 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
 <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
 <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
Message-ID: <wUV5vCNB3AOoOV4xFD0k5dQihit6CHIETo9shtx96YE=.41b4a400-6f4f-4f62-bdbb-a2c88c792328@github.com>

On Tue, 19 Aug 2025 14:57:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The motivation to move into `CollectedHeap::before_exit` is that now we finally have a specific method that is called for GC activites during exit so there is no need to conflate java.cpp with these tasks.
>> 
>>> this calls back to Universe
>> 
>> It called back to Universe in java.cpp too. Maybe you would want `Universe::print_on` to be refactored into CollectedHeap too? If that's the case maybe we should save that for a separate issue.
>> 
>>  > CLDG printing is not necessarily tired to heap
>> 
>> That could be so, but it is put under `gc+exit` tag. Are you suggesting that we should break this apart and do it under another tag?
>
>> now we finally have a specific method that is called for GC activites...
> 
> Then, it should be in `Universe::before_exit`, not inside heap.

FWIW; `Universe::print_on` do actually call collected heap as well.


void Universe::print_on(outputStream* st) {
  GCMutexLocker hl(Heap_lock); // Heap_lock might be locked by caller thread.
  st->print_cr("Heap");

  StreamIndentor si(st, 1);
  heap()->print_heap_on(st);
  MetaspaceUtils::print_on(st);
}


I would be OK with moving it to `Universe::before_exit` and I can see the argument that the log message is conflated with components that are not strictly GC. That being said, I think it would also make sense from a code perspective to put it under GC as the log tag is defined to be GC. The best solution would probably be to redefine the log tags and break the block apart, but that would be out-of-scope for this PR. I'll wait for @kstefanj input before proceeding.

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

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

From duke at openjdk.org  Tue Aug 19 16:03:42 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 16:03:42 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
 <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
 <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
Message-ID: <2wSybZnJX_B_94UbbiPj_gMeKGqoFeyhXk8AAtiM9lQ=.6ae7d021-fd81-425d-b47a-bf767ad7b4dd@github.com>

On Tue, 19 Aug 2025 15:00:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it.
>> 
>> If you look at e.g. `WeakProcessor::CountingClosure`  the following is defined
>> 
>>   size_t dead() const { return _old_dead + _new_dead; }
>>   size_t new_dead() const { return _new_dead; }
>>   size_t total() const { return dead() + _live; }
>> 
>> 
>> so having such convenience method in hotspot is not unprecedented and I would prefer keeping it.
>> 
>> `statistics()` is a less important convenience method that can be removed.
>
> I think the smallest API would be `statisics()`, which returns all sub-components, and consumers of this API can calculate other derived metrics. YMMV.

I would remove `CPUTimeUsage::GC::statistics()` as I would prefer having coherent types between classes in the namespace and since using structs over of classes defeats some of the utility of putting everything into a namespace.

For instance, it makes little sense to define a struct for `Runtime` which only include one component currently and it would be less than ideal to return `jlong` for some classes and custom structs for others if we only have to pick one of these approaches.

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

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

From cjplummer at openjdk.org  Tue Aug 19 19:00:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 19 Aug 2025 19:00:39 GMT
Subject: RFR: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
In-Reply-To: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
References: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
Message-ID: <fhvJLoySe788mx5lGc6Kwec5Lu9K_vCCyGDttTr-bMk=.b314287b-536a-4bf5-b56a-7cc8beca7a73@github.com>

On Tue, 19 Aug 2025 14:18:15 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> The fix for [JDK-8279005](https://bugs.openjdk.org/browse/JDK-8279005) also fixed [JDK-8248691](https://bugs.openjdk.org/browse/JDK-8248691) and [JDK-8268211](https://bugs.openjdk.org/browse/JDK-8268211), which latter two are closed as dups. So, I've removed all jstatLineCountsX.sh from the ProblemList. I propose this patch is trivial.

Looks good. I tested on linux-aarch. I can't speak for the ppc platforms.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26844#pullrequestreview-3133487112

From phh at openjdk.org  Tue Aug 19 20:06:41 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 19 Aug 2025 20:06:41 GMT
Subject: RFR: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
In-Reply-To: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
References: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
Message-ID: <sERCcMn1gp-CKEZS3PsZZectPiaPSWCazL5A48MHJlM=.f92dc9d7-a653-4199-8dfb-b7d7dedb2c47@github.com>

On Tue, 19 Aug 2025 14:18:15 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> The fix for [JDK-8279005](https://bugs.openjdk.org/browse/JDK-8279005) also fixed [JDK-8248691](https://bugs.openjdk.org/browse/JDK-8248691) and [JDK-8268211](https://bugs.openjdk.org/browse/JDK-8268211), which latter two are closed as dups. So, I've removed all jstatLineCountsX.sh from the ProblemList. I propose this patch is trivial.

Thanks, Chris.

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

PR Comment: https://git.openjdk.org/jdk/pull/26844#issuecomment-3202056363

From pchilanomate at openjdk.org  Tue Aug 19 21:32:40 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 19 Aug 2025 21:32:40 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <POtW6Q5sBINfz3VlSkAj_802AFvVFwtsyui5s_nXcCg=.5d30973a-6a23-4b73-b430-b06eddda99bc@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <POtW6Q5sBINfz3VlSkAj_802AFvVFwtsyui5s_nXcCg=.5d30973a-6a23-4b73-b430-b06eddda99bc@github.com>
Message-ID: <xOrLVfHZ1KlLE1SEzfEOiDYrCV2mRHGWFjc0DnOiJf8=.912d0b77-017b-44fa-9476-d7d17fcfbf57@github.com>

On Tue, 19 Aug 2025 05:54:13 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - The oop preservation and exception handling has been fixed.
>  - Test added.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192
>  - added _
>  - wong phase
>  - fixed name
>  - simplified after feedback
>  - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state

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

> 1842:   // Additionally, the result oop should be preserved while the thread is in java.
> 1843:   BasicType type = current_frame.interpreter_frame_result(&oop_result, &value);
> 1844: 

We could add the following assert here (or in `frame::interpreter_frame_result`):

`assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0, ??);`

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

> 1848:   // Deferred transition to VM, so we can stash away the return oop before GC
> 1849:   // Note that this transition is not needed when throwing an exception, because
> 1850:   // there is no oop to retain.

This sentence about not needing the transition should be removed.

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

> 1851:   JvmtiThreadState *state;
> 1852:   {
> 1853:     ThreadInVMfromJava tiv(thread);

The `JRT_BLOCK` below can be moved up. We always transition to vm anyways, so we don?t need the extra `ThreadInVMfromJava`.

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 1:

> 1: /*

Shouldn't this file be placed in `test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred` along with the cpp file?

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 52:

> 50:             enable();
> 51:             exceptionExit();
> 52:             disableAndCheck();

`disableAndCheck` should be moved after the try-catch block otherwise we will never call it.

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 62:

> 60:   if (upcall_method == nullptr) {
> 61:     fatal(jni,"Can't find upCall method.");
> 62:   }

Missing the upcall (not noticed now because of never calling `disableAndCheck`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286328220
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286358481
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286331388
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286355238
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286335516
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286337948

From dholmes at openjdk.org  Tue Aug 19 21:41:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 21:41:42 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>
References: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>
Message-ID: <0DEFfBCDPJsd5_MXkS5Uo1gAI-SYfnhKtnomWrC4G4I=.d8e4efe9-ce78-48bf-9df4-e75b0a1ffbc1@github.com>

On Fri, 25 Jul 2025 01:40:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> EDIT: I've just realized that the `[[nodiscard]]` attribute is not currently permitted. So I may have to revise this aspect of the changes.
> 
> This is a proposal to standardize on the use of os::snprintf and os::snprintf_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of jio_printf at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf...

I am replacing this PR with a refreshed one.

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

PR Comment: https://git.openjdk.org/jdk/pull/26470#issuecomment-3202320187

From dholmes at openjdk.org  Tue Aug 19 21:41:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 21:41:43 GMT
Subject: Withdrawn: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>
References: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>
Message-ID: <Jc0qJTFY71x04QWXkZUCUfZme4CHC0ka9Ydok_uAhvc=.8f2ad11f-20e7-4e0f-a7f1-b34c4fff2728@github.com>

On Fri, 25 Jul 2025 01:40:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> EDIT: I've just realized that the `[[nodiscard]]` attribute is not currently permitted. So I may have to revise this aspect of the changes.
> 
> This is a proposal to standardize on the use of os::snprintf and os::snprintf_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of jio_printf at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf...

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Tue Aug 19 22:09:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 22:09:19 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
Message-ID: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>

This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)

From: https://bugs.openjdk.org/browse/JDK-8347707

The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.

To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.

The potential errors are, generally speaking, not something we should encounter in our own well-written code:

- encoding error: not applicable as we are not using extended character sets
- invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
- mal-formed formatting directives
- overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).

As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.

The potential clients of this API then fall into a number of camps:

1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.

For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.

2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.

For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.

3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.

These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.

4. Those who present a buffer but know that truncation is a possibility, and either need to handle it themselves, or else need to use the return value in subsequent operations.

These clients are also directed to use `os::snprintf`.

In summary we provide the following API:
- `[[nodiscard]] int os::vsnprintf` is the building block for the other methods, it:
  - asserts on precondition failures
  - asserts on error
  - guarantees null-termination in the case of unexpected errors (as the standards are still unclear on that point
  - is declared `[[nodiscard[]]` so that callers cannot ignore the return value (they can explicitly cast to `void` to indicate they don't need it)
- `void os::snprintf_checked`
  - calls `os::vnsprintf`` so asserts on errors
  - asserts on truncation
- `[[nodiscard]] int os::snprintf`
  - calls `os::vnsprintf` so asserts on errors

In terms of the effects on the existing code we:
- Change callers of `::snprintf`/`os::snprintf` that ignore the return value and ensure the buffer is large enough to use `os::snprintf_checked`
  - those that allow truncation to happen must use `os::snprintf`.
- Change all callers of `::snprintf`/`os::snprintf` that use the return value to use `os::snprintf`, plus any additional assertions needed
- Change the 9 callers of `os::snprintf_checked` that do use the return value, to use `os::snprintf` with their own assertions added
- Callers of `os::vnsprintf` are adjusted as needed

The PR  is comprising multiple dependent commits so that you can view things in stages.  There are 46 modified files. The bulk of the changes replace calls to `snprintf`/`os::snprintf` with calls to `os::snprintf_checked`.

Note the use of `[[nodiscard]]` is permitted but not yet documented as such in the style-guide.

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

Commit messages:
 - Merge
 - 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/26849/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26849&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347707
  Stats: 195 lines in 46 files changed: 14 ins; 5 del; 176 mod
  Patch: https://git.openjdk.org/jdk/pull/26849.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26849/head:pull/26849

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

From lmesnik at openjdk.org  Tue Aug 19 23:25:23 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Aug 2025 23:25:23 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v6]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <QFhXTnMpCcHvWRsEJQIPDGxSuHsFQwB8buwCrEGviLI=.522e291b-ab7e-4cf4-87ca-bce165600254@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 three additional commits since the last revision:

 - moved JRT_BLOCK
 - added assertion and removed comment.
 - test fixed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/d9d21af6..32b08587

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

  Stats: 34 lines in 3 files changed: 14 ins; 7 del; 13 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  Tue Aug 19 23:25:24 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Aug 2025 23:25:24 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <xOrLVfHZ1KlLE1SEzfEOiDYrCV2mRHGWFjc0DnOiJf8=.912d0b77-017b-44fa-9476-d7d17fcfbf57@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <POtW6Q5sBINfz3VlSkAj_802AFvVFwtsyui5s_nXcCg=.5d30973a-6a23-4b73-b430-b06eddda99bc@github.com>
 <xOrLVfHZ1KlLE1SEzfEOiDYrCV2mRHGWFjc0DnOiJf8=.912d0b77-017b-44fa-9476-d7d17fcfbf57@github.com>
Message-ID: <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com>

On Tue, 19 Aug 2025 21:17:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - The oop preservation and exception handling has been fixed.
>>  - Test added.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192
>>  - added _
>>  - wong phase
>>  - fixed name
>>  - simplified after feedback
>>  - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state
>
> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 1:
> 
>> 1: /*
> 
> Shouldn't this file be placed in `test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred` along with the cpp file?

It makes test name 
serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java
so it is better to left it on this level
And tests usually have single lib*.cpp per directory.

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

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

From lmesnik at openjdk.org  Tue Aug 19 23:28:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Aug 2025 23:28:39 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <xOrLVfHZ1KlLE1SEzfEOiDYrCV2mRHGWFjc0DnOiJf8=.912d0b77-017b-44fa-9476-d7d17fcfbf57@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <POtW6Q5sBINfz3VlSkAj_802AFvVFwtsyui5s_nXcCg=.5d30973a-6a23-4b73-b430-b06eddda99bc@github.com>
 <xOrLVfHZ1KlLE1SEzfEOiDYrCV2mRHGWFjc0DnOiJf8=.912d0b77-017b-44fa-9476-d7d17fcfbf57@github.com>
Message-ID: <Q8JFSAVi2cBBpZKbhUOf671C494IyOTZZXTCluOhrNw=.60e16da6-384a-4eea-a2a9-9d1ffb67c34e@github.com>

On Tue, 19 Aug 2025 21:02:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - The oop preservation and exception handling has been fixed.
>>  - Test added.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192
>>  - added _
>>  - wong phase
>>  - fixed name
>>  - simplified after feedback
>>  - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1844:
> 
>> 1842:   // Additionally, the result oop should be preserved while the thread is in java.
>> 1843:   BasicType type = current_frame.interpreter_frame_result(&oop_result, &value);
>> 1844: 
> 
> We could add the following assert here (or in `frame::interpreter_frame_result`):
> 
> `assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0, ??);`

Thanks, added.

> src/hotspot/share/prims/jvmtiExport.cpp line 1853:
> 
>> 1851:   JvmtiThreadState *state;
>> 1852:   {
>> 1853:     ThreadInVMfromJava tiv(thread);
> 
> The `JRT_BLOCK` below can be moved up. We always transition to vm anyways, so we don?t need the extra `ThreadInVMfromJava`.

I tried to do this in the first implementation, probably because of other problems. Seems, it can be done now. I run some testing to verify this fix.

> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 62:
> 
>> 60:   if (upcall_method == nullptr) {
>> 61:     fatal(jni,"Can't find upCall method.");
>> 62:   }
> 
> Missing the upcall (not noticed now because of never calling `disableAndCheck`).

Thanks, I removed it right before final clean up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286603703
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286603775
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286604585

From dholmes at openjdk.org  Wed Aug 20 02:35:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 02:35:38 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
Message-ID: <ZoYzKkxnDLWtS1fQgbDmqSP9Ar1BI6J5XXEmLk4fpew=.e1ebcb5c-ad21-4010-9e3d-27eaca630f58@github.com>

On Tue, 19 Aug 2025 08:42:15 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:
> 
>   Remove unused

I'll leave it to the GC folk to approve, but the shared code changes look good to me.

Thanks

src/hotspot/share/services/cpuTimeUsage.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

When refactoring code into a new file, the first copyright year for the new file should be the earliest copyright year of the substantial code/content in that file?not the year the new file is created.

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

PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3134573286
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2286823424

From lmesnik at openjdk.org  Wed Aug 20 04:58:20 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 04:58:20 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@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:

  NULL replaced

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/32b08587..0008f725

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

  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 dholmes at openjdk.org  Wed Aug 20 05:37:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 05:37:43 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@github.com>
Message-ID: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>

On Wed, 20 Aug 2025 04:58:20 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:
> 
>   NULL replaced

I'm very confused by this issue. The description indicates we are calling `get_jvmti_thread_state` from the wrong state, but nowhere here or in JBS do I see anything showing me the actual failing code path. JBS has a part of a hs_err file that reports "# fatal error: LEAF method calling lock? " but I don't see how that relates to the stated problem of being in the wrong state ??

Also you state `post_method_exit` is not called when the method terminates via an exception, but I can't see that as being the case. The MethodExit callback in JVMTI is called under all termination conditions and post_method_exit seems similarly unconditional. ??

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 32:

> 30:  * @run main/othervm/native -agentlib:ExceptionOccurred ExceptionOccurred
> 31:  */
> 32: public class ExceptionOccurred {

I'm very confused by the naming here: what exception has occurred where?

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 42:

> 40: 
> 41: 
> 42:     // Called from ExcptionExit MethodExit callback via JNI

Suggestion:

    // Called from ExceptionExit MethodExit callback via JNI

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 32:

> 30: bool method_exit_posted = false;
> 31: static void JNICALL
> 32: cbMethodExit(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jmethodID method,

Can you add a comment describing the logic of this callback function please. I cannot make sense of the logic below. How many times will this callback get executed?

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

PR Review: https://git.openjdk.org/jdk/pull/26713#pullrequestreview-3134777503
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286990333
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286984860
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286995606

From dholmes at openjdk.org  Wed Aug 20 05:37:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 05:37:45 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v6]
In-Reply-To: <QFhXTnMpCcHvWRsEJQIPDGxSuHsFQwB8buwCrEGviLI=.522e291b-ab7e-4cf4-87ca-bce165600254@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <QFhXTnMpCcHvWRsEJQIPDGxSuHsFQwB8buwCrEGviLI=.522e291b-ab7e-4cf4-87ca-bce165600254@github.com>
Message-ID: <mGIbGfNfx6ISzrQDOJt7f_9j3IwlWmX_SqnropJ2N50=.ebbbf973-cce6-4280-8fe9-10ff598af6b1@github.com>

On Tue, 19 Aug 2025 23:25:23 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 three additional commits since the last revision:
> 
>  - moved JRT_BLOCK
>  - added assertion and removed comment.
>  - test fixed.

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

> 1837:   value.l = 0L;
> 1838:   // post_method_exist is called only when the method is not exit because of
> 1839:   // exception so result should be always initialized.

Suggestion:

  // post_method_exit is only called when the method exits normally,
  // so result should be always initialized.

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

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

From dholmes at openjdk.org  Wed Aug 20 05:37:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 05:37:46 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <POtW6Q5sBINfz3VlSkAj_802AFvVFwtsyui5s_nXcCg=.5d30973a-6a23-4b73-b430-b06eddda99bc@github.com>
 <xOrLVfHZ1KlLE1SEzfEOiDYrCV2mRHGWFjc0DnOiJf8=.912d0b77-017b-44fa-9476-d7d17fcfbf57@github.com>
 <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com>
Message-ID: <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com>

On Tue, 19 Aug 2025 23:22:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 1:
>> 
>>> 1: /*
>> 
>> Shouldn't this file be placed in `test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred` along with the cpp file?
>
> It makes test name 
> serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java
> so it is better to left it on this level
> And tests usually have single lib*.cpp per directory.

It is normal/common to have a directory Foo that contains both Foo.java and libFoo.cpp

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

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

From lmesnik at openjdk.org  Wed Aug 20 05:47:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 05:47:54 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v8]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <9_uLv6OW8fN5Ow5KAK2fLwEJpUrDjGbE8--Az6wO480=.db6786c7-6485-4582-94f4-768d38ac0019@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:

  Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/0008f725..320b93eb

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

  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 20 06:30:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 06:30:39 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@github.com>
 <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>
Message-ID: <MTsEojCF4SzX_dxJsubJEBDXjS5Of6u1DMiPg47U2tk=.e8d8eb29-815e-4b02-8711-2e5597360818@github.com>

On Wed, 20 Aug 2025 05:35:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm very confused by this issue. The description indicates we are calling `get_jvmti_thread_state` from the wrong state, but nowhere here or in JBS do I see anything showing me the actual failing code path. JBS has a part of a hs_err file that reports "# fatal error: LEAF method calling lock? " but I don't see how that relates to the stated problem of being in the wrong state ??
> 

The comment in JBS shows the stacktrace from hs_err. I copied it here:
Stack: [0x00007f13537f9000,0x00007f13538f9000], sp=0x00007f13538f6b60, free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x10c4458] JavaThread::check_for_valid_safepoint_state()+0xc8 (javaThread.cpp:401)
V [libjvm.so+0x16fe5e1] Mutex::lock()+0x41 (mutex.cpp:119)
V [libjvm.so+0x1403b7b] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x39b (mutexLocker.hpp:204)
V [libjvm.so+0x140b178] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool) [clone .constprop.0]+0x98 (jvmtiExport.cpp:424)
V [libjvm.so+0x1415b57] JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x77 (jvmtiExport.cpp:1834)
V [libjvm.so+0x1066b86] InterpreterRuntime::post_method_exit(JavaThread*)+0xe6 (interpreterRuntime.cpp:1278)

Also, I updated another comment to show how to reproduce the bug. The testing is not integrated in CI yet. However, it could be reproduced using our tests.

Also, the problem could be quite easy reproduced if assertion from the patch is added to 
`
JvmtiExport::get_jvmti_thread_state(JavaThread *thread, bool allow_suspend) {
`

> Also you state `post_method_exit` is not called when the method terminates via an exception, but I can't see that as being the case. The MethodExit callback in JVMTI is called under all termination conditions and post_method_exit seems similarly unconditional. ??


The method 
`
void JvmtiExport::post_method_exit_inner(JavaThread* thread,
                                         methodHandle& mh,
                                         JvmtiThreadState *state,
                                         bool exception_exit,
                                         frame current_frame,
                                         jvalue& value) {
`
is used by 
`void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame) {`
to post MethodExit events.
And 
`
void JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) {
`
that also calls `JvmtiExport::post_method_exit_inner()` is used only when method exit normally. 

T `JvmtiExport::post_method_exit()` has the variable `exception_exit`.  This variable is set to true while the thread has exception that has been thrown but haven't caught yet.  It might happens if VM or JNI made upcall while thread has ES_DETECTED _exception_state. So current method is exit normally while thread is processing exception. Pretty rare case that is reproduced in the test 'ExceptionOccured'. 
The method is called from MethodExit event for the method where exception has been thrown.

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

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

From lmesnik at openjdk.org  Wed Aug 20 06:36:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 06:36:58 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v9]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <eM5LB8ESb17fmgq0trC6PYo8deyCvW20ddT52lCplOA=.06a231fe-07ca-4efa-b9f5-2055331769dc@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:

  added comments to the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/320b93eb..6960b1aa

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

  Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 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 20 06:46:03 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 06:46:03 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v10]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <PyEajoYEsqmAmLvUGXb8YTmDXLDL2lPs2ysUni8RvD0=.08ac3ea0-dd64-4c21-b164-7f90f170466b@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:

  Update src/hotspot/share/prims/jvmtiExport.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/6960b1aa..67d87dbb

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

  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 lmesnik at openjdk.org  Wed Aug 20 06:46:03 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 06:46:03 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <POtW6Q5sBINfz3VlSkAj_802AFvVFwtsyui5s_nXcCg=.5d30973a-6a23-4b73-b430-b06eddda99bc@github.com>
 <xOrLVfHZ1KlLE1SEzfEOiDYrCV2mRHGWFjc0DnOiJf8=.912d0b77-017b-44fa-9476-d7d17fcfbf57@github.com>
 <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com>
 <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com>
Message-ID: <Q8hSr_4n_1xZZBm9TvZ2pgZ-F65t37CF5QXPws8dvCA=.67b0f56b-bb64-4b5c-a47e-0e66081857e1@github.com>

On Wed, 20 Aug 2025 04:59:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It makes test name 
>> serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java
>> so it is better to left it on this level
>> And tests usually have single lib*.cpp per directory.
>
> It is normal/common to have a directory Foo that contains both Foo.java and libFoo.cpp

The test name would be 
test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java
I don't like this duplication.

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

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

From lmesnik at openjdk.org  Wed Aug 20 06:46:03 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 06:46:03 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@github.com>
 <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>
Message-ID: <V4z3viWlDijXdcnVV8GXfPlIYuB06h8Mcpo4JyCd844=.37678103-42b3-4be1-b9b1-3e438bc69848@github.com>

On Wed, 20 Aug 2025 05:04:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   NULL replaced
>
> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 32:
> 
>> 30:  * @run main/othervm/native -agentlib:ExceptionOccurred ExceptionOccurred
>> 31:  */
>> 32: public class ExceptionOccurred {
> 
> I'm very confused by the naming here: what exception has occurred where?

The exception was thrown in the current thread/  However, the current method is not unwinded. It is called using JNI while  the thread has already thrown but not yet caught exception. 
I thought to name it MethodExitWhileExceptionPending, however full name would be 
serviceability/jvmti/events/MethodExit/MethodExitWhileExceptionPending/MethodExitWhileExceptionPending.java
so I started to "reduce" it.
Moved to upper directory and removed MethodExit. Also the state looks similar to 'ExceptionOccurred' for JNI method. Let me know if you have better name in the mind.

> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 32:
> 
>> 30: bool method_exit_posted = false;
>> 31: static void JNICALL
>> 32: cbMethodExit(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jmethodID method,
> 
> Can you add a comment describing the logic of this callback function please. I cannot make sense of the logic below. How many times will this callback get executed?

Done, hope it makes logic clearer.

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

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

From mbaesken at openjdk.org  Wed Aug 20 06:54:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Aug 2025 06:54:41 GMT
Subject: RFR: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
In-Reply-To: <4qidglHH5GBkTrOWg5RjvQHgvDFNU4z1VPbj9V3bTdo=.82952c1a-5ac6-4384-b7b0-3bee23e862d4@github.com>
References: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
 <4qidglHH5GBkTrOWg5RjvQHgvDFNU4z1VPbj9V3bTdo=.82952c1a-5ac6-4384-b7b0-3bee23e862d4@github.com>
Message-ID: <58GKoyT8HqdxSCXIv45KSWZAlJJxZ4o_08AIw1JK9dA=.cb33a3dc-b2aa-4bc6-83f1-7e0ea21b4f00@github.com>

On Tue, 19 Aug 2025 15:16:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> @MBaesken , @ArnoZeller can you please check if the test can be removed from the problem list on linux-ppc64le and AIX?

I put it into our build/tests , will run it there for some time to check for issues on the ppc platforms.
(I am out of office for some days soon so might take a bit of time until I respond again)

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

PR Comment: https://git.openjdk.org/jdk/pull/26844#issuecomment-3204429492

From dholmes at openjdk.org  Wed Aug 20 07:36:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 07:36:43 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <Q8hSr_4n_1xZZBm9TvZ2pgZ-F65t37CF5QXPws8dvCA=.67b0f56b-bb64-4b5c-a47e-0e66081857e1@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <POtW6Q5sBINfz3VlSkAj_802AFvVFwtsyui5s_nXcCg=.5d30973a-6a23-4b73-b430-b06eddda99bc@github.com>
 <xOrLVfHZ1KlLE1SEzfEOiDYrCV2mRHGWFjc0DnOiJf8=.912d0b77-017b-44fa-9476-d7d17fcfbf57@github.com>
 <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com>
 <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com>
 <Q8hSr_4n_1xZZBm9TvZ2pgZ-F65t37CF5QXPws8dvCA=.67b0f56b-bb64-4b5c-a47e-0e66081857e1@github.com>
Message-ID: <7K0TQY1mJpEYAuY4KLK8GJJupooahpMEQOdiVLTNRm4=.bd623d94-e03c-4890-b803-973226de8e43@github.com>

On Wed, 20 Aug 2025 06:42:38 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> It is normal/common to have a directory Foo that contains both Foo.java and libFoo.cpp
>
> The test name would be 
> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java
> I don't like this duplication.

It is common to use a `Test` prefix on the actual file so we have directory `foo`, containing `TestFoo.java` and `libFoo.cpp` (or 'libTestFoo.cpp`). The point is that all the source files for one test reside in the same directory unless a different structure is needed for some reason. Placing the native code in its own subdirectory looks very odd to me. But of course there is no general consistency here and it depends on who wrote the test cases and when.

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

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

From dholmes at openjdk.org  Wed Aug 20 07:44:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 07:44:37 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <MTsEojCF4SzX_dxJsubJEBDXjS5Of6u1DMiPg47U2tk=.e8d8eb29-815e-4b02-8711-2e5597360818@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@github.com>
 <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>
 <MTsEojCF4SzX_dxJsubJEBDXjS5Of6u1DMiPg47U2tk=.e8d8eb29-815e-4b02-8711-2e5597360818@github.com>
Message-ID: <uMCfNgefRgg3Bo1T8OT6JjKJE192G5mRTADNPjst4O0=.b199617f-b69d-44f2-a2d5-afcd9cc6c706@github.com>

On Wed, 20 Aug 2025 06:28:26 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The comment in JBS shows the stacktrace from hs_err.

But nothing in that hs_err snippet indicates that the problem is we are in the wrong state.

> void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame)` that also calls `JvmtiExport::post_method_exit_inner()` is used only when method exit normally.

Thanks for clarifying. I was looking at remove_activation in the interpreter and did not see any special exception processing path.

> So current method is exit normally while thread is processing exception.

Still struggling with this part. So the method exited normally then as part of event processing a Java upcall can raise an exception? But according to the spec any such exceptions get dropped - so is the flag just to do the dropping?

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

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

From dholmes at openjdk.org  Wed Aug 20 07:50:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 07:50:39 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <V4z3viWlDijXdcnVV8GXfPlIYuB06h8Mcpo4JyCd844=.37678103-42b3-4be1-b9b1-3e438bc69848@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@github.com>
 <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>
 <V4z3viWlDijXdcnVV8GXfPlIYuB06h8Mcpo4JyCd844=.37678103-42b3-4be1-b9b1-3e438bc69848@github.com>
Message-ID: <rrNdi3lEnoLgwdj5mpsfwKaH1x8-ayGGo1IRMgu8cPY=.425c72aa-0965-4431-b058-60e0818ee453@github.com>

On Wed, 20 Aug 2025 05:49:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 32:
>> 
>>> 30:  * @run main/othervm/native -agentlib:ExceptionOccurred ExceptionOccurred
>>> 31:  */
>>> 32: public class ExceptionOccurred {
>> 
>> I'm very confused by the naming here: what exception has occurred where?
>
> The exception was thrown in the current thread/  However, the current method is not unwinded. It is called using JNI while  the thread has already thrown but not yet caught exception. 
> I thought to name it MethodExitWhileExceptionPending, however full name would be 
> serviceability/jvmti/events/MethodExit/MethodExitWhileExceptionPending/MethodExitWhileExceptionPending.java
> so I started to "reduce" it.
> Moved to upper directory and removed MethodExit. Also the state looks similar to 'ExceptionOccurred' for JNI method. Let me know if you have better name in the mind.

Well `ExceptionExit` is slightly clearer and ties in with `exceptionExit()`.

Before this fix what happens if you run this test case?

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

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

From dholmes at openjdk.org  Wed Aug 20 07:50:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 07:50:40 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v10]
In-Reply-To: <PyEajoYEsqmAmLvUGXb8YTmDXLDL2lPs2ysUni8RvD0=.08ac3ea0-dd64-4c21-b164-7f90f170466b@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <PyEajoYEsqmAmLvUGXb8YTmDXLDL2lPs2ysUni8RvD0=.08ac3ea0-dd64-4c21-b164-7f90f170466b@github.com>
Message-ID: <ilDTIrA-JnqeIw73QWfdx7BeVCswV5170HWNvdjGubA=.98ecb447-2e21-4299-b8d1-83edb053771d@github.com>

On Wed, 20 Aug 2025 06:46:03 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:
> 
>   Update src/hotspot/share/prims/jvmtiExport.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 35:

> 33: //    has been popped by exception and call 'upCall' mthod using JNI.
> 34: // 2) for upCall method it verifies that event has correct
> 35: //    return value and was not popped by execption.

Suggestion:

//    return value and was not popped by exception.

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

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

From sjohanss at openjdk.org  Wed Aug 20 08:17:43 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 20 Aug 2025 08:17:43 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <wUV5vCNB3AOoOV4xFD0k5dQihit6CHIETo9shtx96YE=.41b4a400-6f4f-4f62-bdbb-a2c88c792328@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
 <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
 <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
 <wUV5vCNB3AOoOV4xFD0k5dQihit6CHIETo9shtx96YE=.41b4a400-6f4f-4f62-bdbb-a2c88c792328@github.com>
Message-ID: <XmOqCGscMAFtbqBS5IRsO625xeMAhhjU3jcy6ZMWPbk=.7aae9e83-4fc2-47bf-84a8-e4af27e2d1ef@github.com>

On Tue, 19 Aug 2025 15:54:29 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>>> now we finally have a specific method that is called for GC activites...
>> 
>> Then, it should be in `Universe::before_exit`, not inside heap.
>
> FWIW; `Universe::print_on` do actually call collected heap as well.
> 
> 
> void Universe::print_on(outputStream* st) {
>   GCMutexLocker hl(Heap_lock); // Heap_lock might be locked by caller thread.
>   st->print_cr("Heap");
> 
>   StreamIndentor si(st, 1);
>   heap()->print_heap_on(st);
>   MetaspaceUtils::print_on(st);
> }
> 
> 
> I would be OK with moving it to `Universe::before_exit` and I can see the argument that the log message is conflated with components that are not strictly GC. That being said, I think it would also make sense from a code perspective to put it under GC as the log tag is defined to be GC. The best solution would probably be to redefine the log tags and break the block apart, but that would be out-of-scope for this PR. I'll wait for @kstefanj input before proceeding.

I'm good with moving it to `Universe::before_exit` as well. Looks like a good fit now when it was added.

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

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

From duke at openjdk.org  Wed Aug 20 09:00:30 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 20 Aug 2025 09:00:30 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v11]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@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:

  Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/79a3323a..f29d5af4

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

  Stats: 74 lines in 4 files changed: 22 ins; 45 del; 7 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 ayang at openjdk.org  Wed Aug 20 10:41:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 20 Aug 2025 10:41:44 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v11]
In-Reply-To: <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@github.com>
Message-ID: <EeD3lyiym3t4NmCCIWlXF_c2YiAKwKyCfCsryHgEYh8=.32590bcb-0fa5-4abe-8fd5-c096d59aaa87@github.com>

On Wed, 20 Aug 2025 09:00:30 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:
> 
>   Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit

src/hotspot/share/memory/universe.cpp line 1318:

> 1316:   }
> 1317: 
> 1318:   const double vm_thread_cpu_time = (double) CPUTimeUsage::Runtime::vm_thread() / NANOSECS_PER_SEC;

Does `vm_thread_cpu_time` include gc-vm-thread time? Looking at how it's printed, "VM Thread" and "Garbage Collection" are two separate lines, suggesting there are no overlapping btw them.

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

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

From dholmes at openjdk.org  Wed Aug 20 12:55:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:55:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

@sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

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

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

From syan at openjdk.org  Wed Aug 20 14:28:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 20 Aug 2025 14:28:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
Message-ID: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>

On Wed, 20 Aug 2025 12:53:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
>> 
>> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1
>
> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.

So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).

I do agree this change, what I mean is this change has some side effect.

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

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

From lmesnik at openjdk.org  Wed Aug 20 14:43:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 14:43:44 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v11]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <d_69kB08oNXooU_yHCat_GDpIEmBK1I5ijp_Krf2nTY=.1d0ce79a-28a4-4125-8445-04859913c490@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:

  Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/67d87dbb..106e5a1f

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

  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 20 14:52:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 14:52:41 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <uMCfNgefRgg3Bo1T8OT6JjKJE192G5mRTADNPjst4O0=.b199617f-b69d-44f2-a2d5-afcd9cc6c706@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@github.com>
 <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>
 <MTsEojCF4SzX_dxJsubJEBDXjS5Of6u1DMiPg47U2tk=.e8d8eb29-815e-4b02-8711-2e5597360818@github.com>
 <uMCfNgefRgg3Bo1T8OT6JjKJE192G5mRTADNPjst4O0=.b199617f-b69d-44f2-a2d5-afcd9cc6c706@github.com>
Message-ID: <NX_KcHve6PBJwGIbcnLE6Ka1G_Z1Vvnf2lqLwLX3MdY=.8566db24-2881-41c0-b56b-e1c461787038@github.com>

On Wed, 20 Aug 2025 07:41:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Still struggling with this part. So the method exited normally then as part of event processing a Java upcall can raise an exception? But according to the spec any such exceptions get dropped - so is the flag just to do the dropping?

Vice versa. 
The exception is thrown in "usual" method. Usually, the stack is unwinded until exception is caught. However, it is possible to call the method (using upCall) in the middle of this process. And this 'upCall'  method doesn't throw or caught any exceptions. Should just work normally.

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

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

From lmesnik at openjdk.org  Wed Aug 20 15:02:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 15:02:39 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v5]
In-Reply-To: <7K0TQY1mJpEYAuY4KLK8GJJupooahpMEQOdiVLTNRm4=.bd623d94-e03c-4890-b803-973226de8e43@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <POtW6Q5sBINfz3VlSkAj_802AFvVFwtsyui5s_nXcCg=.5d30973a-6a23-4b73-b430-b06eddda99bc@github.com>
 <xOrLVfHZ1KlLE1SEzfEOiDYrCV2mRHGWFjc0DnOiJf8=.912d0b77-017b-44fa-9476-d7d17fcfbf57@github.com>
 <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com>
 <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com>
 <Q8hSr_4n_1xZZBm9TvZ2pgZ-F65t37CF5QXPws8dvCA=.67b0f56b-bb64-4b5c-a47e-0e66081857e1@github.com>
 <7K0TQY1mJpEYAuY4KLK8GJJupooahpMEQOdiVLTNRm4=.bd623d94-e03c-4890-b803-973226de8e43@github.com>
Message-ID: <uR43kYAAZ_UwmXZjAx7Nn3Fjv-NzBc42VxtLKGvDZi4=.1a9f0bd7-6079-4b71-b740-90f6ded02f14@github.com>

On Wed, 20 Aug 2025 07:34:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The test name would be 
>> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java
>> I don't like this duplication.
>
> It is common to use a `Test` prefix on the actual file so we have directory `foo`, containing `TestFoo.java` and `libFoo.cpp` (or 'libTestFoo.cpp`). The point is that all the source files for one test reside in the same directory unless a different structure is needed for some reason. Placing the native code in its own subdirectory looks very odd to me. But of course there is no general consistency here and it depends on who wrote the test cases and when.

let me rename it to
serviceability/jvmti/events/MethodExit/PendingException/TestMethodExitWithPendingException.java
is ti make more clear? 
The "upcall" is used in the test only to call some method in the middle of exception handling.

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

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

From lmesnik at openjdk.org  Wed Aug 20 15:02:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 15:02:40 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <rrNdi3lEnoLgwdj5mpsfwKaH1x8-ayGGo1IRMgu8cPY=.425c72aa-0965-4431-b058-60e0818ee453@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@github.com>
 <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>
 <V4z3viWlDijXdcnVV8GXfPlIYuB06h8Mcpo4JyCd844=.37678103-42b3-4be1-b9b1-3e438bc69848@github.com>
 <rrNdi3lEnoLgwdj5mpsfwKaH1x8-ayGGo1IRMgu8cPY=.425c72aa-0965-4431-b058-60e0818ee453@github.com>
Message-ID: <6WnMC2pVTGGsJvoBNA3DEFTXps1C-RjUzHlfBlVki-I=.b225d746-10fb-4488-bc98-83bf7a0552d1@github.com>

On Wed, 20 Aug 2025 07:47:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The exception was thrown in the current thread/  However, the current method is not unwinded. It is called using JNI while  the thread has already thrown but not yet caught exception. 
>> I thought to name it MethodExitWhileExceptionPending, however full name would be 
>> serviceability/jvmti/events/MethodExit/MethodExitWhileExceptionPending/MethodExitWhileExceptionPending.java
>> so I started to "reduce" it.
>> Moved to upper directory and removed MethodExit. Also the state looks similar to 'ExceptionOccurred' for JNI method. Let me know if you have better name in the mind.
>
> Well `ExceptionExit` is slightly clearer and ties in with `exceptionExit()`.
> 
> Before this fix what happens if you run this test case?

Before my fix, the MethodExit for 'upCall' method has been called with 
was_popped_by_exception = true and return_value  = nullptr, like it existed with popping exception.

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

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

From ihse at openjdk.org  Wed Aug 20 15:19:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:19:42 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

I don't think there is any point linking to the build source code. 

Suggestion:

certain amount of time will apply this factor. If you run in
forced compilation mode (`-Xcomp`) using `make test`, it
will automatically adjust this factor to compensate for the
interpreter not being as fast as JITed code. Defaults to 1.

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

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

From ihse at openjdk.org  Wed Aug 20 15:24:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:24:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.

I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 

Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

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

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

From cjplummer at openjdk.org  Wed Aug 20 15:31:40 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 20 Aug 2025 15:31:40 GMT
Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException
 and NativeMethodException are thrown [v3]
In-Reply-To: <p-LhRBL8vfENrYul7GRgQoyXO0F8jehXkeqMxS_3uhk=.8210c66c-292b-4be8-af1e-13cb663b2c4e@github.com>
References: <DsrI8MGX3CvRq2jc-v16JqLErUd4Np8EZy1FDY7Zdro=.0f07987e-0566-47e1-a2ed-aa260f3c190a@github.com>
 <p-LhRBL8vfENrYul7GRgQoyXO0F8jehXkeqMxS_3uhk=.8210c66c-292b-4be8-af1e-13cb663b2c4e@github.com>
Message-ID: <JGstVW4W5C7rW4B7wZOywhMJDnERbZOsejCCNoUClrI=.77e949a8-edb0-4275-8ace-0154eaa44c84@github.com>

On Fri, 18 Jul 2025 23:55:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error.
>> 
>> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException.
>> 
>> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given.
>> 
>> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CSR and complete testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor rewording

Thanks for the reviews Alan, Alex, and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/26335#issuecomment-3201081553

From cjplummer at openjdk.org  Wed Aug 20 15:34:44 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 20 Aug 2025 15:34:44 GMT
Subject: Integrated: 8309400: JDI spec needs to clarify when
 OpaqueFrameException and NativeMethodException are thrown
In-Reply-To: <DsrI8MGX3CvRq2jc-v16JqLErUd4Np8EZy1FDY7Zdro=.0f07987e-0566-47e1-a2ed-aa260f3c190a@github.com>
References: <DsrI8MGX3CvRq2jc-v16JqLErUd4Np8EZy1FDY7Zdro=.0f07987e-0566-47e1-a2ed-aa260f3c190a@github.com>
Message-ID: <801ly7dsYvcs1gqT2-cWtLGCktb5eGXKRhyzkLHt2TQ=.2fbc00e9-f0eb-4bcf-8946-75f37f94367c@github.com>

On Tue, 15 Jul 2025 22:07:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error.
> 
> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException.
> 
> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given.
> 
> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CSR and complete testing.

This pull request has now been integrated.

Changeset: 9041f4c4
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9041f4c47f3c9b90abe825f652f572351060c96a
Stats:     35 lines in 3 files changed: 5 ins; 10 del; 20 mod

8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown

Reviewed-by: sspitsyn, alanb, amenkov

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

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

From eastigeevich at openjdk.org  Wed Aug 20 15:46:43 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 20 Aug 2025 15:46:43 GMT
Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses()
 and class linking
Message-ID: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>

There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.

This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.

Tested fastdebug and release builds: Linux x86_64 and arm64
- The reproducer from JDK-8277444 passed.
- Tier1 - tier3 passed.

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

Commit messages:
 - 8277444: Race condition on Instrumentation.retransformClasses() and class linking

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

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

From eastigeevich at openjdk.org  Wed Aug 20 15:46:46 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 20 Aug 2025 15:46:46 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking
In-Reply-To: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
Message-ID: <GLWyCA8GrPm-N1lgLYME_3sCBO1h7cqSMlu6e5PFYFY=.d42ae04f-8da2-4f7c-b576-229f45dee853@github.com>

On Wed, 20 Aug 2025 15:36:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
> 
> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
> 
> Tested fastdebug and release builds: Linux x86_64 and arm64
> - The reproducer from JDK-8277444 passed.
> - Tier1 - tier3 passed.

Hi @coleenp,
Could you please take a look?

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

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

From lmesnik at openjdk.org  Wed Aug 20 15:54:05 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 15:54:05 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v12]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <zvG9jJN2yN8AdG50F7zmiLVjikOM0BPXO7xksyg_Zlw=.f6060ae8-b3fc-437b-8e61-4178bef4016e@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:

  test renamed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/106e5a1f..ce132751

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

  Stats: 116 lines in 3 files changed: 56 ins; 56 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 lkorinth at openjdk.org  Wed Aug 20 16:27:39 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 16:27:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
Message-ID: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>

On Wed, 20 Aug 2025 15:17:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> I don't think there is any point linking to the build source code. 
> 
> Suggestion:
> 
> certain amount of time will apply this factor. If you run in
> forced compilation mode (`-Xcomp`) using `make test`, it
> will automatically adjust this factor to compensate for the
> interpreter not being as fast as JITed code. Defaults to 1.

I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

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

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

From lmesnik at openjdk.org  Wed Aug 20 16:48:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Aug 2025 16:48:56 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v13]
In-Reply-To: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
Message-ID: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@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 comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26713/files
  - new: https://git.openjdk.org/jdk/pull/26713/files/ce132751..d56e3536

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

  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 lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@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:

  update testing.md, remove makefile link, fix bad text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/286a2cc6..f24a1e72

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

  Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 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 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
 <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
Message-ID: <2Ba-EiFMVh1-nMHcihw93nZq-TkQNtvHc244Bwe8I40=.cfa54a17-0a3f-465d-a1c3-7560965376d7@github.com>

On Wed, 20 Aug 2025 16:24:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> I don't think there is any point linking to the build source code. 
>> 
>> Suggestion:
>> 
>> certain amount of time will apply this factor. If you run in
>> forced compilation mode (`-Xcomp`) using `make test`, it
>> will automatically adjust this factor to compensate for the
>> interpreter not being as fast as JITed code. Defaults to 1.
>
> I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

fixed

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

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

From eastigeevich at openjdk.org  Wed Aug 20 17:31:22 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 20 Aug 2025 17:31:22 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v2]
In-Reply-To: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
Message-ID: <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>

> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
> 
> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
> 
> Tested fastdebug and release builds: Linux x86_64 and arm64
> - The reproducer from JDK-8277444 passed.
> - Tier1 - tier3 passed.

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

  Add missing include runtime/synchronizer.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26863/files
  - new: https://git.openjdk.org/jdk/pull/26863/files/4882b2db..d6895181

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

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

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

From ihse at openjdk.org  Wed Aug 20 19:36:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 19:36:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <Pw1uYaqAPK95BsoZ0xgNA1c3rsXjxHCiz-xACzocwqA=.e6cb7fcf-4438-4e4a-aeef-7d9c707c87c8@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

Build changes look good now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

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

From kbarrett at openjdk.org  Wed Aug 20 20:19:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 20 Aug 2025 20:19:39 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

I noticed there are a number of calls with `buflen - 1`. Probably from the bad
old days when some snprintf variants didn't guarantee null termination. I
didn't see forced null terminations for the few I spot-checked though, and
it's not obvious in some cases that the final byte is certain to be null going
in. Nothing to be done about that here, but there might be some following
cleanup work called for.

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

> 4799:     char buf [16]; // according to glibc manpage, 16 chars incl. '/0'
> 4800:     (void) os::snprintf(buf, sizeof(buf), "%s", name);
> 4801:     buf[sizeof(buf) - 1] = '\0';

pre-existing.  Adding null termination at the end hasn't been needed for a while. There are probably
others like this that can be deferred to following cleanup.

src/hotspot/os/posix/attachListener_posix.cpp line 351:

> 349:   int n = os::snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d",
> 350:                        os::get_temp_directory(), os::current_process_id());
> 351:   assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow");

I don't see any other uses of `n` besides this assert. Maybe this should be using `os::snprintf_checked`?

src/hotspot/share/opto/idealGraphPrinter.cpp line 644:

> 642:         // Only use up to 4 chars and fall back to a generic "I" to keep it short.
> 643:         int written_chars = os::snprintf(buffer, sizeof(buffer), "%d", value);
> 644:         if (written_chars > 0 && written_chars <= 4) {

I don't understand the addition of `written_chars > 0` here and line 658?

src/hotspot/share/runtime/os.hpp line 810:

> 808:   // Performs vsnprintf and asserts the result is non-negative (so there was not
> 809:   // an encoding error or any other kind of usage error).
> 810:   [[nodiscard]] static int vsnprintf(char* buf, size_t len, const char* fmt, va_list args) ATTRIBUTE_PRINTF(3, 0);

Consider moving the `ATTRIBUTE_PRINTF` to the front so all the attributes are together?
And maybe a line break between the attributes and the signature, just to avoid pushing the
signature way over to the right.

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

PR Review: https://git.openjdk.org/jdk/pull/26849#pullrequestreview-3138069291
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289177595
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289182600
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289195737
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289201763

From dlong at openjdk.org  Wed Aug 20 21:23:36 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 20 Aug 2025 21:23:36 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <PbADd4u7EmBU7pjkN6wcPdHJIXqr2eXsCEm2dDtrAXA=.494b3350-9371-4486-987b-bf25b9abb011@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

Could we map snprintf to os::snprintf_checked with a macro or some kind of namespace magic?  It would reduce the number of files changed and catch any new cases of snprintf that might get accidentally added in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3208122700

From dholmes at openjdk.org  Wed Aug 20 21:32:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 21:32:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <j5ndr4sR6OHgBGlCY-e1I-VdfMKpG2GS98Wv2qbshtU=.d5aad200-1bc2-4080-ad71-218c59a7e491@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, 

@magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

For this exercise existing explicit timeout values need to be multiplied by 4 to keep the same absolute timeout value. In addition a number of tests that use the implicit default timeout (120*4) now need an explicit timeout (480 generally).

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

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

From dlong at openjdk.org  Wed Aug 20 21:55:36 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 20 Aug 2025 21:55:36 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <Hmt3c2mNVEianKx4WIVhs9MHNM1j7BrcdvlGt7I_yyQ=.c57aef4e-efe7-405b-8e84-84004ae7979a@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 727:

> 725: 
> 726:   int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 ");
> 727:   get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len);

Suggestion:

  int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 ");
  if (desc_len < CPU_DETAILED_DESC_BUF_SIZE) {
    get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len);
  }

If there is truncation, _cpu_desc + desc_len will be past the end of the buffer and CPU_DETAILED_DESC_BUF_SIZE - desc_len will be negative in get_compatible_board(), which will cause problems when converted to size_t.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289384784

From dlong at openjdk.org  Wed Aug 20 22:24:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 20 Aug 2025 22:24:58 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

src/hotspot/os/aix/attachListener_aix.cpp line 423:

> 421:     log_trace(attach)("Failed to find attach file: %s, trying alternate", fn);
> 422:     os::snprintf_checked(fn, sizeof(fn), "%s/.attach_pid%d",
> 423:                          os::get_temp_directory(), os::current_process_id());

This could fail if os::get_temp_directory() returns an extremely long path.  How about doing a truncation check like at line 354?

src/hotspot/os/aix/os_aix.cpp line 1055:

> 1053:     if (ebuf != nullptr && ebuflen > 0) {
> 1054:       os::snprintf_checked(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
> 1055:                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);

Suggestion:

      (void) os::snprintf(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
                           filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);

This could easily truncate, based on LIBPATH and LD_LIBRARY_PATH.

src/hotspot/os/aix/os_aix.cpp line 1097:

> 1095:   struct utsname name;
> 1096:   uname(&name);
> 1097:   os::snprintf_checked(buf, buflen, "%s %s", name.release, name.version);

Suggestion:

  (void) os::snprintf(buf, buflen, "%s %s", name.release, name.version);

src/hotspot/os/aix/porting_aix.cpp line 939:

> 937:   // retrieve the path to the currently running executable binary
> 938:   // to open it
> 939:   os::snprintf_checked(buffer, 100, "/proc/%ld/object/a.out", (long)getpid());

Suggestion:

  os::snprintf_checked(buffer, sizeof(buffer), "/proc/%ld/object/a.out", (long)getpid());

src/hotspot/os/aix/porting_aix.cpp line 1157:

> 1155:       }
> 1156:       if (ebuf != nullptr && ebuflen > 0) {
> 1157:         os::snprintf_checked(ebuf, ebuflen - 1, "%s", error_report);

Suggestion:

        (void) os::snprintf(ebuf, ebuflen - 1, "%s", error_report);

src/hotspot/share/gc/shared/satbMarkQueue.cpp line 324:

> 322: 
> 323:     virtual void do_thread(Thread* t) {
> 324:       os::snprintf_checked(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());

Suggestion:

      (void) os::snprintf(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());

Can this be a JavaThread with an arbitrarily long name()?

src/hotspot/share/utilities/virtualizationSupport.cpp line 76:

> 74:     if (sg_error == VMGUESTLIB_ERROR_SUCCESS) {
> 75:       has_host_information = true;
> 76:       os::snprintf_checked(host_information, sizeof(host_information), "%s", result_info);

Are these two guaranteed not to overflow/truncate?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289418676
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289425021
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289426575
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289429123
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289430247
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289397586
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289406269

From dlong at openjdk.org  Wed Aug 20 23:02:51 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 20 Aug 2025 23:02:51 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <7bUyzA85sBzPhzJMPaLcMflpd4QPUUXBy5z0A7gNbnE=.335d09e8-d7fc-4381-b77e-71c2636748d1@github.com>

On Wed, 20 Aug 2025 22:13:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/os/aix/attachListener_aix.cpp line 423:
> 
>> 421:     log_trace(attach)("Failed to find attach file: %s, trying alternate", fn);
>> 422:     os::snprintf_checked(fn, sizeof(fn), "%s/.attach_pid%d",
>> 423:                          os::get_temp_directory(), os::current_process_id());
> 
> This could fail if os::get_temp_directory() returns an extremely long path.  How about doing a truncation check like at line 354?

Nevermind, same thing.  We would need to fix a lot of code if os::get_temp_directory() returned a pathologically long string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289472350

From dholmes at openjdk.org  Thu Aug 21 00:05:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 00:05:57 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking
In-Reply-To: <GLWyCA8GrPm-N1lgLYME_3sCBO1h7cqSMlu6e5PFYFY=.d42ae04f-8da2-4f7c-b576-229f45dee853@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GLWyCA8GrPm-N1lgLYME_3sCBO1h7cqSMlu6e5PFYFY=.d42ae04f-8da2-4f7c-b576-229f45dee853@github.com>
Message-ID: <AlSwOJB03loDaqfBBs1NoLOvPCyQw9ro6wfWNCZ2UNU=.d2ccd321-e785-4cc4-911f-0785ed747b17@github.com>

On Wed, 20 Aug 2025 15:43:03 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Hi @coleenp,
> Could you please take a look?

@eastig I am not sure about this one. Can you clarify please how you can be transforming a class that has not yet been linked? If this is possible then it seems to me we are missing a call to ensure linkage.

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

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

From dholmes at openjdk.org  Thu Aug 21 01:41:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 01:41:53 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v7]
In-Reply-To: <NX_KcHve6PBJwGIbcnLE6Ka1G_Z1Vvnf2lqLwLX3MdY=.8566db24-2881-41c0-b56b-e1c461787038@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <IXgZMEwYoTDFV6MeP61k9HXnxr2Xl6R6uwrAPaGu_y0=.86efd2d3-ea7a-4564-b77b-1165b9eb4973@github.com>
 <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com>
 <MTsEojCF4SzX_dxJsubJEBDXjS5Of6u1DMiPg47U2tk=.e8d8eb29-815e-4b02-8711-2e5597360818@github.com>
 <uMCfNgefRgg3Bo1T8OT6JjKJE192G5mRTADNPjst4O0=.b199617f-b69d-44f2-a2d5-afcd9cc6c706@github.com>
 <NX_KcHve6PBJwGIbcnLE6Ka1G_Z1Vvnf2lqLwLX3MdY=.8566db24-2881-41c0-b56b-e1c461787038@github.com>
Message-ID: <8JW0vmIDxZSwqe1jTVrG2jgUWzgK91TdEQCCs7TIwro=.a56ec3fc-4d7c-463d-aa11-f2329bac69aa@github.com>

On Wed, 20 Aug 2025 14:50:25 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Vice versa. The exception is thrown in "usual" method. Usually, the stack is unwinded until exception is caught. However, it is possible to call the method (using upCall) in the middle of this process. And this 'upCall' method doesn't throw or caught any exceptions. Should just work normally.

So the callback does an upcall that invokes the same method we are still posting the "method exit" for. That is a distinct frame/activation so the exit mode of the original should be immaterial. Though not sure how we avoid infinite loop in such a recursive case.

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

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

From dholmes at openjdk.org  Thu Aug 21 02:00:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 02:00:57 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v13]
In-Reply-To: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com>
Message-ID: <IDOt14S1fcCIFgTn0BguFZP7Zx1PBrkZg1Fioqx7YNE=.4173b8b4-46de-4725-8750-c32e69742383@github.com>

On Wed, 20 Aug 2025 16:48:56 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:
> 
>   fixed comment.

To fix the actual, simple, problem of being in the wrong state, it seems to me that this earlier suggestion is far easier to understand:

  {
    ThreadInVMfromJava __tiv(thread);
    state = get_jvmti_thread_state(thread);
  }

With the proposed deferral of the `get_jvmti_thread_state` and the deferred check for `is_interp_only_mode` I am left wondering if it is okay to call:

current_frame.interpreter_frame_result(&oop_result, &value);
current_frame.interpreter_frame_expression_stack_size() > 0

if we may not be in interp_only mode?

If the concern is the overhead of `ThreadInVMfromJava` can't we cheat here and use a direct state change as we are going from one safepoint-unsafe state to another?

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

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

From dholmes at openjdk.org  Thu Aug 21 05:37:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 05:37:52 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
Message-ID: <6mwFNPgecEzR5PYjXk61WNnz3KrKFIgiRhBxUy5W4H4=.846ebbef-9b26-47e2-937e-5be9c4bfe3b4@github.com>

On Wed, 20 Aug 2025 20:03:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/os/linux/os_linux.cpp line 4801:
> 
>> 4799:     char buf [16]; // according to glibc manpage, 16 chars incl. '/0'
>> 4800:     (void) os::snprintf(buf, sizeof(buf), "%s", name);
>> 4801:     buf[sizeof(buf) - 1] = '\0';
> 
> pre-existing.  Adding null termination at the end hasn't been needed for a while. There are probably
> others like this that can be deferred to following cleanup.

Okay I have filed [JDK-8365896](https://bugs.openjdk.org/browse/JDK-8365896) to clean this up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289902515

From dholmes at openjdk.org  Thu Aug 21 05:40:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 05:40:51 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
Message-ID: <vuvqkzwTfev5-30GKomtO_uU9FA5LOc-3WmtyxHM_Gs=.5e747bfa-d109-4b70-8cc6-15aeed4794b7@github.com>

On Wed, 20 Aug 2025 20:05:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/os/posix/attachListener_posix.cpp line 351:
> 
>> 349:   int n = os::snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d",
>> 350:                        os::get_temp_directory(), os::current_process_id());
>> 351:   assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow");
> 
> I don't see any other uses of `n` besides this assert. Maybe this should be using `os::snprintf_checked`?

Agreed - changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289906758

From dholmes at openjdk.org  Thu Aug 21 05:45:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 05:45:52 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
Message-ID: <chK5pTh1EuC4GUMm1fyr4GV_HS6HWkPQ1mDvQqU1280=.3808e7b1-953e-495d-b246-63f217186fcd@github.com>

On Wed, 20 Aug 2025 20:12:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/share/opto/idealGraphPrinter.cpp line 644:
> 
>> 642:         // Only use up to 4 chars and fall back to a generic "I" to keep it short.
>> 643:         int written_chars = os::snprintf(buffer, sizeof(buffer), "%d", value);
>> 644:         if (written_chars > 0 && written_chars <= 4) {
> 
> I don't understand the addition of `written_chars > 0` here and line 658?

Well in theory, in a release build, `os::snprintf` could return -1 and I didn't want any static analysis tools pointing this out to me later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289912608

From dholmes at openjdk.org  Thu Aug 21 06:00:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:00:51 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <PbADd4u7EmBU7pjkN6wcPdHJIXqr2eXsCEm2dDtrAXA=.494b3350-9371-4486-987b-bf25b9abb011@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <PbADd4u7EmBU7pjkN6wcPdHJIXqr2eXsCEm2dDtrAXA=.494b3350-9371-4486-987b-bf25b9abb011@github.com>
Message-ID: <kRbYl_y9DmuZDKgwra2hz2RRlk0FnVXRSg2N2Fchtng=.a3c139d6-e68e-466f-a269-70be79c81c39@github.com>

On Wed, 20 Aug 2025 21:20:50 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> Could we map snprintf to os::snprintf_checked with a macro or some kind of namespace magic?  It would reduce the number of files changed and catch any new cases of snprintf that might get accidentally added in the future.

Thanks for looking at this @dean-long !

> Could we map snprintf to os::snprintf_checked with a macro or some kind of namespace magic? It would reduce the number of files changed and catch any new cases of snprintf that might get accidentally added in the future.

Raw `snprintf` is now prohibited so no future accidental additions are possible. I don't think hiding the fact we are not using the library `snprintf` is a good thing either.

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3209102280

From dholmes at openjdk.org  Thu Aug 21 06:06:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:06:52 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <Hmt3c2mNVEianKx4WIVhs9MHNM1j7BrcdvlGt7I_yyQ=.c57aef4e-efe7-405b-8e84-84004ae7979a@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <Hmt3c2mNVEianKx4WIVhs9MHNM1j7BrcdvlGt7I_yyQ=.c57aef4e-efe7-405b-8e84-84004ae7979a@github.com>
Message-ID: <uV3sVWzxe7N1AhvxVk8XeT5kwwfZhq1mmiezaqHAvG8=.da944b8c-21ea-4861-9b69-d27a51d965c5@github.com>

On Wed, 20 Aug 2025 21:53:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 727:
> 
>> 725: 
>> 726:   int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 ");
>> 727:   get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len);
> 
> Suggestion:
> 
>   int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 ");
>   if (desc_len < CPU_DETAILED_DESC_BUF_SIZE) {
>     get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len);
>   }
> 
> If there is truncation, _cpu_desc + desc_len will be past the end of the buffer and CPU_DETAILED_DESC_BUF_SIZE - desc_len will be negative in get_compatible_board(), which will cause problems when converted to size_t.

There cannot be truncation here. We are writing a fixed-size string of 8 characters (plus nul-terminator) to a buffer of size 4096.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289943417

From dholmes at openjdk.org  Thu Aug 21 06:25:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:25:52 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <M4J7UWfsMdIrOZTjEbPBGCeE6SyxG9tTgzgDUVkuRC8=.44e4e513-a139-4c2b-9465-c6c26b745b7c@github.com>

On Wed, 20 Aug 2025 21:59:17 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/share/gc/shared/satbMarkQueue.cpp line 324:
> 
>> 322: 
>> 323:     virtual void do_thread(Thread* t) {
>> 324:       os::snprintf_checked(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());
> 
> Suggestion:
> 
>       (void) os::snprintf(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());
> 
> Can this be a JavaThread with an arbitrarily long name()?

Yes it could - thanks. It is likely enough that we could hit this during testing that asserting if it happens is not really useful. Long Java thread names are not necessarily errors to be fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289969498

From dholmes at openjdk.org  Thu Aug 21 06:25:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:25:53 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <M4J7UWfsMdIrOZTjEbPBGCeE6SyxG9tTgzgDUVkuRC8=.44e4e513-a139-4c2b-9465-c6c26b745b7c@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
 <M4J7UWfsMdIrOZTjEbPBGCeE6SyxG9tTgzgDUVkuRC8=.44e4e513-a139-4c2b-9465-c6c26b745b7c@github.com>
Message-ID: <y2oW-0shWVXbE05RROhwYMHtfXOXb-AO_0ksRP1b3Ss=.3640272c-0273-4751-b3c3-221e22561f19@github.com>

On Thu, 21 Aug 2025 06:21:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/satbMarkQueue.cpp line 324:
>> 
>>> 322: 
>>> 323:     virtual void do_thread(Thread* t) {
>>> 324:       os::snprintf_checked(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());
>> 
>> Suggestion:
>> 
>>       (void) os::snprintf(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());
>> 
>> Can this be a JavaThread with an arbitrarily long name()?
>
> Yes it could - thanks. It is likely enough that we could hit this during testing that asserting if it happens is not really useful. Long Java thread names are not necessarily errors to be fixed.

In addition, if we were to hit such a name we are not likely to increase the buffer size just for this extreme case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289973406

From dholmes at openjdk.org  Thu Aug 21 06:28:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:28:56 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <6JAI2s1fJRYWYXtcyA_b2Bhn_7_GGAc67YuAFoGUrso=.55792b10-d6c0-4625-84b2-953ace2cf039@github.com>

On Wed, 20 Aug 2025 22:05:10 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/share/utilities/virtualizationSupport.cpp line 76:
> 
>> 74:     if (sg_error == VMGUESTLIB_ERROR_SUCCESS) {
>> 75:       has_host_information = true;
>> 76:       os::snprintf_checked(host_information, sizeof(host_information), "%s", result_info);
> 
> Are these two guaranteed not to overflow/truncate?

The issue is not whether they can overflow, but if they do is it something we want to detect during testing so we can take action - e.g. by increasing the buffer size. This is very subjective, but my initial position in most cases has been yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289978047

From dholmes at openjdk.org  Thu Aug 21 06:33:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:33:51 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7bUyzA85sBzPhzJMPaLcMflpd4QPUUXBy5z0A7gNbnE=.335d09e8-d7fc-4381-b77e-71c2636748d1@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
 <7bUyzA85sBzPhzJMPaLcMflpd4QPUUXBy5z0A7gNbnE=.335d09e8-d7fc-4381-b77e-71c2636748d1@github.com>
Message-ID: <5WIH7DnsEDDENhwj3xVo2Y7Qq6g7ULcdkoGnJWAlZZE=.09e34d8a-048d-4e01-9ada-d0fd54ff6ee4@github.com>

On Wed, 20 Aug 2025 22:59:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/os/aix/attachListener_aix.cpp line 423:
>> 
>>> 421:     log_trace(attach)("Failed to find attach file: %s, trying alternate", fn);
>>> 422:     os::snprintf_checked(fn, sizeof(fn), "%s/.attach_pid%d",
>>> 423:                          os::get_temp_directory(), os::current_process_id());
>> 
>> This could fail if os::get_temp_directory() returns an extremely long path.  How about doing a truncation check like at line 354?
>
> Nevermind, same thing.  We would need to fix a lot of code if os::get_temp_directory() returned a pathologically long string.

I've changed line 352 as per Kim's comment above because `snprintf` followed by an assert for truncation is what `snprintf_checked` does.

Again the question to ask is: if we hit this during testing do we think it indicates we need to increase the buffer size. Again I am initially in the yes camp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289987176

From dholmes at openjdk.org  Thu Aug 21 06:38:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:38:55 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <idaZ8CjLSYTU2tp0vkAjZ080E3dWoqPxKVIH8Obw9yk=.89f5598c-8591-4bf0-9d51-88151051c608@github.com>

On Wed, 20 Aug 2025 22:18:28 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/os/aix/os_aix.cpp line 1055:
> 
>> 1053:     if (ebuf != nullptr && ebuflen > 0) {
>> 1054:       os::snprintf_checked(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
>> 1055:                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);
> 
> Suggestion:
> 
>       (void) os::snprintf(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
>                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);
> 
> This could easily truncate, based on LIBPATH and LD_LIBRARY_PATH.

Yes but again if that happens during testing we need to know and fix the buffer size to get the non-truncated values.

> src/hotspot/os/aix/os_aix.cpp line 1097:
> 
>> 1095:   struct utsname name;
>> 1096:   uname(&name);
>> 1097:   os::snprintf_checked(buf, buflen, "%s %s", name.release, name.version);
> 
> Suggestion:
> 
>   (void) os::snprintf(buf, buflen, "%s %s", name.release, name.version);

See previous replies.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289995061
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289996137

From dholmes at openjdk.org  Thu Aug 21 06:38:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:38:56 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
Message-ID: <9ON1pRJ6eZcRYoDahh1w2hCT95YZS9Z_2ORMj-laVZs=.aabd607e-72a7-4c6b-a2b6-8475feff4d41@github.com>

On Wed, 20 Aug 2025 20:15:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/share/runtime/os.hpp line 810:
> 
>> 808:   // Performs vsnprintf and asserts the result is non-negative (so there was not
>> 809:   // an encoding error or any other kind of usage error).
>> 810:   [[nodiscard]] static int vsnprintf(char* buf, size_t len, const char* fmt, va_list args) ATTRIBUTE_PRINTF(3, 0);
> 
> Consider moving the `ATTRIBUTE_PRINTF` to the front so all the attributes are together?
> And maybe a line break between the attributes and the signature, just to avoid pushing the
> signature way over to the right.

I have done that and placed each attribute on its own line (we should have a style guide entry for this :) ). But I note that all the other ATTRIBUTE_PRINTF's are placed after the function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289993291

From dholmes at openjdk.org  Thu Aug 21 06:46:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:46:03 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

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

  Reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26849/files
  - new: https://git.openjdk.org/jdk/pull/26849/files/2de6ac98..38003a22

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

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

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

From dholmes at openjdk.org  Thu Aug 21 06:46:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:46:05 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <4UAB8nFSiBclUHIOuDsRkEpX_ZUma9yvK11iRkMOTtM=.4f9402f4-7f44-4f6e-a854-6e2313c412c9@github.com>

On Wed, 20 Aug 2025 22:21:45 GMT, Dean Long <dlong at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reviewer feedback
>
> src/hotspot/os/aix/porting_aix.cpp line 939:
> 
>> 937:   // retrieve the path to the currently running executable binary
>> 938:   // to open it
>> 939:   os::snprintf_checked(buffer, 100, "/proc/%ld/object/a.out", (long)getpid());
> 
> Suggestion:
> 
>   os::snprintf_checked(buffer, sizeof(buffer), "/proc/%ld/object/a.out", (long)getpid());

It doesn't really matter as we only need at most 30 bytes.

> src/hotspot/os/aix/porting_aix.cpp line 1157:
> 
>> 1155:       }
>> 1156:       if (ebuf != nullptr && ebuflen > 0) {
>> 1157:         os::snprintf_checked(ebuf, ebuflen - 1, "%s", error_report);
> 
> Suggestion:
> 
>         (void) os::snprintf(ebuf, ebuflen - 1, "%s", error_report);

See previous replies.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290002985
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290003771

From dlong at openjdk.org  Thu Aug 21 07:48:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 21 Aug 2025 07:48:57 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <idaZ8CjLSYTU2tp0vkAjZ080E3dWoqPxKVIH8Obw9yk=.89f5598c-8591-4bf0-9d51-88151051c608@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
 <idaZ8CjLSYTU2tp0vkAjZ080E3dWoqPxKVIH8Obw9yk=.89f5598c-8591-4bf0-9d51-88151051c608@github.com>
Message-ID: <qqr1wCRNhu-dnJWGmqNiJpokOR6i23eHaH84qRjNFBw=.0cf37006-2bb8-4509-99c1-3b0db4ed39f0@github.com>

On Thu, 21 Aug 2025 06:35:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/aix/os_aix.cpp line 1055:
>> 
>>> 1053:     if (ebuf != nullptr && ebuflen > 0) {
>>> 1054:       os::snprintf_checked(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
>>> 1055:                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);
>> 
>> Suggestion:
>> 
>>       (void) os::snprintf(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
>>                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);
>> 
>> This could easily truncate, based on LIBPATH and LD_LIBRARY_PATH.
>
> Yes but again if that happens during testing we need to know and fix the buffer size to get the non-truncated values.

In this case the buffer size comes from shared code.  Whatever size we choose for the static buffer, we can trigger the assert by setting LIBPATH and LD_LIBRARY_PATH to very long strings.  This is just the error message, so it might be OK to truncate it.  Otherwise we could need to allocate the buffer using malloc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290181959

From lkorinth at openjdk.org  Thu Aug 21 09:12:57 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 21 Aug 2025 09:12:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
Message-ID: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>

On Wed, 20 Aug 2025 14:25:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.
>
> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
> 
> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
> 
> I do agree this change, what I mean is this change has some side effect.
> 
>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
> 
> I think I can try it in a new PR.

I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.

I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

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

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

From syan at openjdk.org  Thu Aug 21 09:52:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 21 Aug 2025 09:52:54 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
 <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
Message-ID: <N_1V36WztAVi1O6SdDaGQXa4b8TGB7xGpz5T1TbxL9I=.ea0293e3-eb0b-4d96-bd40-d5c9c4e3fd1d@github.com>

On Thu, 21 Aug 2025 09:10:26 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
>> 
>> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
>> 
>> I do agree this change, what I mean is this change has some side effect.
>> 
>>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
>> 
>> I think I can try it in a new PR.
>
> I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.
> 
> I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

@lkorinth Thanks for your advice sincerely. I think you are right, we need more evaluate cautiously before start to change the timeoutFactor for -Xcomp.

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

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

From duke at openjdk.org  Thu Aug 21 11:59:38 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 21 Aug 2025 11:59:38 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v12]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@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:

  Remove CPUTimeUsage::Runtime

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/f29d5af4..b7fdc0f8

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

  Stats: 12 lines in 3 files changed: 0 ins; 12 del; 0 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 21 11:59:38 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 21 Aug 2025 11:59:38 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v11]
In-Reply-To: <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@github.com>
Message-ID: <knTn92ULPJfoVpr-kyXnIlZSkANc54Rc28NIAVEwKr4=.914f2dba-0d8c-4f53-acc1-2581904ff218@github.com>

On Wed, 20 Aug 2025 09:00:30 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:
> 
>   Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit

I had an offline discussion with @albertnetymk (thanks for bringing this up!) and we both agree that the current definition of `CPUTimeUsage::Runtime::vm_thread()` may be misread. As a consequence, we believe that expanding this interface to include more components would be best served by creating a separate PR that can serve as an explicit discussion for the layout. As such I'm removing `CPUTimeUsage::Runtime` from this PR.

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

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

From ayang at openjdk.org  Thu Aug 21 12:08:56 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 21 Aug 2025 12:08:56 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v12]
In-Reply-To: <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@github.com>
Message-ID: <Irg8M2fUPdf5Z-8QMghZgXH40R5x8zrWRRXvLDtIb9s=.4ef291f5-0d50-46f6-b67c-876f58b54171@github.com>

On Thu, 21 Aug 2025 11:59:38 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:
> 
>   Remove CPUTimeUsage::Runtime

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3140358434

From ihse at openjdk.org  Thu Aug 21 12:21:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Aug 2025 12:21:00 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <zgu5mLb1mA-ca4wxmJJjLNmmq3sJFwWtfjY4yRnmYFQ=.81a024ea-41ce-42cc-9038-3ef40e483793@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.
> 
> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 
> 
> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

> @magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

That is surprising and a bit disappointing. I guess it is not worth the effort to try and figure out why this is the case; it could probably vary from test to test and be difficult to track for little gain. Still, it makes you wonder.

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

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

From kbarrett at openjdk.org  Thu Aug 21 12:23:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 21 Aug 2025 12:23:55 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
Message-ID: <uGR1xhnP0aLT8_PuXtleC9aT0y3JiFclC0YXtYo1LK0=.fcc6460a-b5e7-4c05-81a0-81e3e0896886@github.com>

On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26849#pullrequestreview-3140418082

From kbarrett at openjdk.org  Thu Aug 21 12:23:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 21 Aug 2025 12:23:56 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <9ON1pRJ6eZcRYoDahh1w2hCT95YZS9Z_2ORMj-laVZs=.aabd607e-72a7-4c6b-a2b6-8475feff4d41@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
 <9ON1pRJ6eZcRYoDahh1w2hCT95YZS9Z_2ORMj-laVZs=.aabd607e-72a7-4c6b-a2b6-8475feff4d41@github.com>
Message-ID: <RN-6ZkB7h5TEX6meG2y4jN6o_5pCfpS4FVmXM8bhe2I=.afb0cbc1-9fe9-466f-beb7-62f74ef2e946@github.com>

On Thu, 21 Aug 2025 06:34:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.hpp line 810:
>> 
>>> 808:   // Performs vsnprintf and asserts the result is non-negative (so there was not
>>> 809:   // an encoding error or any other kind of usage error).
>>> 810:   [[nodiscard]] static int vsnprintf(char* buf, size_t len, const char* fmt, va_list args) ATTRIBUTE_PRINTF(3, 0);
>> 
>> Consider moving the `ATTRIBUTE_PRINTF` to the front so all the attributes are together?
>> And maybe a line break between the attributes and the signature, just to avoid pushing the
>> signature way over to the right.
>
> I have done that and placed each attribute on its own line (we should have a style guide entry for this :) ). But I note that all the other ATTRIBUTE_PRINTF's are placed after the function.

What you've done here matches what I did when adding `[[noreturn]]` to `report_xxx` functions
in debug.hpp.  So I'm good with that.  The style guide already has this guidance:
https://github.com/openjdk/jdk/blame/02fe095d29994bec28c85beb6bf2a69b0f49b206/doc/hotspot-style.md#L1120-L1122
There's just lots of old, non-conforming code. :)
I forgot about that when I said "Consider moving", and should have pointed to the style guide.
Whether and where there should be line breaks is something the style guide leaves to authors and reviewers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290880828

From duke at openjdk.org  Thu Aug 21 13:52:53 2025
From: duke at openjdk.org (duke)
Date: Thu, 21 Aug 2025 13:52:53 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v12]
In-Reply-To: <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@github.com>
Message-ID: <7-F_uRu2j1uwCfI9QrIcLpaZ15gJVft_sNJlN7DicRc=.0d4f66ca-77f6-4f8e-bdbd-76fa86dbcaa2@github.com>

On Thu, 21 Aug 2025 11:59:38 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()
>> 
>> 
>> 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   ]      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   ] =====================================================================================
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove CPUTimeUsage::Runtime

@JonasNorlinder 
Your change (at version b7fdc0f8c608ecfdd6a4f6a875b8cd6a58ace5c8) is now ready to be sponsored by a Committer.

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

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

From duke at openjdk.org  Thu Aug 21 14:08:05 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 21 Aug 2025 14:08:05 GMT
Subject: Integrated: 8364638: Refactor and make accumulated GC CPU time code
 generic
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <EzLxrw73zur7r-ktPhTsoGY7XkQvvBnO-0JCJVspKis=.796f3a2a-7486-4bad-990a-6fe3e8bf64a4@github.com>

On Mon, 4 Aug 2025 13:59:43 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()
> 
> 
> 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   ]      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   ] =====================================================================================

This pull request has now been integrated.

Changeset: fb651fd6
Author:    Jonas Norlinder <jonas.norlinder at oracle.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb651fd6d246e69b42363e050eb8d96afb633eed
Stats:     281 lines in 11 files changed: 202 ins; 76 del; 3 mod

8364638: Refactor and make accumulated GC CPU time code generic

Reviewed-by: ayang, sjohanss

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

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

From lmesnik at openjdk.org  Thu Aug 21 14:30:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Aug 2025 14:30:04 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v13]
In-Reply-To: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com>
Message-ID: <rj90kAup2-5LcxqRJo8c5d12Lijo1OyMBVKoNlxvwws=.debba0a3-5d85-422f-9e22-5159ee7b9652@github.com>

On Wed, 20 Aug 2025 16:48:56 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:
> 
>   fixed comment.

I see that that 
post_method_exit in the 
`void InterpreterMacroAssembler::notify_method_exit(..)` 
is called only when thread is in interp_only mode. So it is ok to call 
current_frame.interpreter_frame_result(&oop_result, &value);

I did this, and why I trying to understand what would be result in the case of `exception_exit == true` I realized that it is still safe, because this method always exit normally. 


So let me split this fix into 2 separate issues and fix them separately.  I filed
https://bugs.openjdk.org/browse/JDK-8365937 

to don't change posting because of `exception_exit`

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

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

From lmesnik at openjdk.org  Thu Aug 21 15:56:32 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Aug 2025 15:56:32 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding
Message-ID: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>

The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates
  `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();`
to find if method exit normally or by exception.
However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See
`void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)`
where post_method_exit_inner is called directly.

The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. 


The fix was a part of
https://github.com/openjdk/jdk/pull/26713
for
https://bugs.openjdk.org/browse/JDK-8365192

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

Commit messages:
 - more comments in the test
 - fixed ident
 - bugid fixed:
 - updated to fix 8365937
 - fixed comment.
 - test renamed.
 - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp
 - Update src/hotspot/share/prims/jvmtiExport.cpp
 - added comments to the test
 - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java
 - ... and 13 more: https://git.openjdk.org/jdk/compare/e04a3103...e8343e08

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

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

From lmesnik at openjdk.org  Thu Aug 21 16:01:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Aug 2025 16:01:41 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v2]
In-Reply-To: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
Message-ID: <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>

> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates
>   `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();`
> to find if method exit normally or by exception.
> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See
> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)`
> where post_method_exit_inner is called directly.
> 
> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. 
> 
> 
> The fix was a part of
> https://github.com/openjdk/jdk/pull/26713
> for
> https://bugs.openjdk.org/browse/JDK-8365192

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

  assertion added.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26886/files
  - new: https://git.openjdk.org/jdk/pull/26886/files/e8343e08..d9319d90

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

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

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

From pchilanomate at openjdk.org  Thu Aug 21 18:29:52 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 21 Aug 2025 18:29:52 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v13]
In-Reply-To: <IDOt14S1fcCIFgTn0BguFZP7Zx1PBrkZg1Fioqx7YNE=.4173b8b4-46de-4725-8750-c32e69742383@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com>
 <IDOt14S1fcCIFgTn0BguFZP7Zx1PBrkZg1Fioqx7YNE=.4173b8b4-46de-4725-8750-c32e69742383@github.com>
Message-ID: <zFE_h62KYx-_UI6K9cIfl50e5i1pUC7CrcYe_oWHkKk=.51e2f4e4-aed5-4767-b6e2-7f2a9cdc0f3f@github.com>

On Thu, 21 Aug 2025 01:58:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To fix the actual, simple, problem of being in the wrong state, it seems to me that this earlier suggestion is far easier to understand:
> 
> ```
>   {
>     ThreadInVMfromJava __tiv(thread);
>     state = get_jvmti_thread_state(thread);
>   }
> ```
> 
> With the proposed deferral of the `get_jvmti_thread_state` and the deferred check for `is_interp_only_mode` I am left wondering if it is okay to call:
> 
> ```
> current_frame.interpreter_frame_result(&oop_result, &value);
> current_frame.interpreter_frame_expression_stack_size() > 0
> ```
> 
> if we may not be in interp_only mode?
> 
`InterpreterRuntime::post_method_exit` is only called from the interpreter, so the top frame should always be interpreted.


> If the concern is the overhead of `ThreadInVMfromJava` can't we cheat here and use a direct state change as we are going from one safepoint-unsafe state to another?
>
I think that once we transition to vm there is no point in going back to Java to then possibly transition back to vm. The only reason to delay the transition was to have the `result` Handle be created outside of the `JRT_BLOCK` scope, so that we are able to restore the return oop (if any) after the last safepoint. That means we could move `JRT_BLOCK` even further up, right after declaring the locals.

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

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

From lmesnik at openjdk.org  Thu Aug 21 22:03:57 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Aug 2025 22:03:57 GMT
Subject: RFR: 8365192: post_meth_exit should be in vm state when calling
 get_jvmti_thread_state [v13]
In-Reply-To: <zFE_h62KYx-_UI6K9cIfl50e5i1pUC7CrcYe_oWHkKk=.51e2f4e4-aed5-4767-b6e2-7f2a9cdc0f3f@github.com>
References: <HW0mmljgUYNv_xB7u3WEyQmqnTwCWFzxyukgiLjKYOw=.cc3e38f6-ca0b-4b7d-8baa-7fc842c4db33@github.com>
 <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com>
 <IDOt14S1fcCIFgTn0BguFZP7Zx1PBrkZg1Fioqx7YNE=.4173b8b4-46de-4725-8750-c32e69742383@github.com>
 <zFE_h62KYx-_UI6K9cIfl50e5i1pUC7CrcYe_oWHkKk=.51e2f4e4-aed5-4767-b6e2-7f2a9cdc0f3f@github.com>
Message-ID: <w4EsUTbelsSz1yguKvcaevXmLYbucU80Z4WpYcYRki4=.e8d0c2b0-f695-41ec-8f2b-192545135e85@github.com>

On Thu, 21 Aug 2025 18:27:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> To fix the actual, simple, problem of being in the wrong state, it seems to me that this earlier suggestion is far easier to understand:
>> 
>>   {
>>     ThreadInVMfromJava __tiv(thread);
>>     state = get_jvmti_thread_state(thread);
>>   }
>> 
>> With the proposed deferral of the `get_jvmti_thread_state` and the deferred check for `is_interp_only_mode` I am left wondering if it is okay to call:
>> 
>> current_frame.interpreter_frame_result(&oop_result, &value);
>> current_frame.interpreter_frame_expression_stack_size() > 0
>> 
>> if we may not be in interp_only mode?
>> 
>> If the concern is the overhead of `ThreadInVMfromJava` can't we cheat here and use a direct state change as we are going from one safepoint-unsafe state to another?
>
>> To fix the actual, simple, problem of being in the wrong state, it seems to me that this earlier suggestion is far easier to understand:
>> 
>> ```
>>   {
>>     ThreadInVMfromJava __tiv(thread);
>>     state = get_jvmti_thread_state(thread);
>>   }
>> ```
>> 
>> With the proposed deferral of the `get_jvmti_thread_state` and the deferred check for `is_interp_only_mode` I am left wondering if it is okay to call:
>> 
>> ```
>> current_frame.interpreter_frame_result(&oop_result, &value);
>> current_frame.interpreter_frame_expression_stack_size() > 0
>> ```
>> 
>> if we may not be in interp_only mode?
>> 
> `InterpreterRuntime::post_method_exit` is only called from the interpreter, so the top frame should always be interpreted.
> 
> 
>> If the concern is the overhead of `ThreadInVMfromJava` can't we cheat here and use a direct state change as we are going from one safepoint-unsafe state to another?
>>
> I think that once we transition to vm there is no point in going back to Java to then possibly transition back to vm. The only reason to delay the transition was to have the `result` Handle be created outside of the `JRT_BLOCK` scope, so that we are able to restore the return oop (if any) after the last safepoint. That means we could move `JRT_BLOCK` even further up, right after declaring the locals.

Agree with @pchilano, the only oop handling should be done before JRT_BLOCK. And the part dealing with with `exception_exit` will be implemented separately in the:
https://github.com/openjdk/jdk/pull/26886

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

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

From eastigeevich at openjdk.org  Thu Aug 21 23:36:51 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 21 Aug 2025 23:36:51 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking
In-Reply-To: <GLWyCA8GrPm-N1lgLYME_3sCBO1h7cqSMlu6e5PFYFY=.d42ae04f-8da2-4f7c-b576-229f45dee853@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GLWyCA8GrPm-N1lgLYME_3sCBO1h7cqSMlu6e5PFYFY=.d42ae04f-8da2-4f7c-b576-229f45dee853@github.com>
Message-ID: <qHdwTBdp0-bWywVQLp75FRfKo1-aCnrw5WHq2xvXyyM=.30a746db-2959-45fd-bff3-d97f00fddef5@github.com>

On Wed, 20 Aug 2025 15:43:03 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Hi @coleenp,
> Could you please take a look?

> @eastig I am not sure about this one. Can you clarify please how you can be transforming a class that has not yet been linked? If this is possible then it seems to me we are missing a call to ensure linkage.

Hi @dholmes-ora,

I checked what was happening.

The reproducer from JDK-8277444 simplified:
- Thread 1 does:

bigClass = Class.forName();
consumer.accept(bigClass); // Puts bigClass in QUEUE
final Object o = bigClass.getConstructor().newInstance();
System.out.println(o.hashCode());


- Thread 2 does:

final Class<?> aClass = QUEUE.take();
Instrumentation.retransformClasses(aClass); 


`Class.forName` does not link `bigClass`. So an unlinked class is put in a queue. The linking process starts when we start using `bigClass`.
Thread 2 gets unlinked `bigClass` from the queue. It can request to retransform  before we start using it and the linking process starts.

So we can have the linking process and the retransforming process running in parallel. There is no synchronization between them. We get a race condition. `bigClass` is big enough to make the linking process running long.

I think `Class.forName` does not do linking intentionally, for performance reasons.

I hope I've got everything correctly from logs and sources.

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

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

From prr at openjdk.org  Fri Aug 22 05:54:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 05:54:55 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:

> 48:  * @summary URL.getContent() should return SoundClip for supported formats
> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
> 50:  */

I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

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

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

From dholmes at openjdk.org  Fri Aug 22 06:38:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Aug 2025 06:38:56 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <GGszb14v2jX1mI4BbHtgkXQDlgFehKYtLl3yUr0zX40=.1952e76e-0a5c-4be9-944a-505f84d89624@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

@prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

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

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

From dholmes at openjdk.org  Fri Aug 22 06:45:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Aug 2025 06:45:56 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking
In-Reply-To: <qHdwTBdp0-bWywVQLp75FRfKo1-aCnrw5WHq2xvXyyM=.30a746db-2959-45fd-bff3-d97f00fddef5@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GLWyCA8GrPm-N1lgLYME_3sCBO1h7cqSMlu6e5PFYFY=.d42ae04f-8da2-4f7c-b576-229f45dee853@github.com>
 <qHdwTBdp0-bWywVQLp75FRfKo1-aCnrw5WHq2xvXyyM=.30a746db-2959-45fd-bff3-d97f00fddef5@github.com>
Message-ID: <wBKmBh0G0nlXzOM7z5L0QJoFT0SKRd50C7CUBs0zf3U=.419dc51c-7363-4485-9463-184006b8cac8@github.com>

On Thu, 21 Aug 2025 23:34:13 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Hi @coleenp,
>> Could you please take a look?
>
>> @eastig I am not sure about this one. Can you clarify please how you can be transforming a class that has not yet been linked? If this is possible then it seems to me we are missing a call to ensure linkage.
> 
> Hi @dholmes-ora,
> 
> I checked what was happening.
> 
> The reproducer from JDK-8277444 simplified:
> - Thread 1 does:
> 
> bigClass = Class.forName();
> consumer.accept(bigClass); // Puts bigClass in QUEUE
> final Object o = bigClass.getConstructor().newInstance();
> System.out.println(o.hashCode());
> 
> 
> - Thread 2 does:
> 
> final Class<?> aClass = QUEUE.take();
> Instrumentation.retransformClasses(aClass); 
> 
> 
> `Class.forName` does not link `bigClass`. So an unlinked class is put in a queue. The linking process starts when we start using `bigClass`.
> Thread 2 gets unlinked `bigClass` from the queue. It can request to retransform  before we start using it and the linking process starts.
> 
> So we can have the linking process and the retransforming process running in parallel. There is no synchronization between them. We get a race condition. `bigClass` is big enough to make the linking process running long.
> 
> I think `Class.forName` does not do linking intentionally, for performance reasons.
> 
> I hope I've got everything correctly from logs and sources.

@eastig Thank you very much for that detailed analysis. An interesting scenario. I still find it somewhat suspect that we can transform an unlinked class and wonder if we should instead ensure it is linked first, rather than trying to coordinate the two pieces of code via the use of the init_lock. ?

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

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

From duke at openjdk.org  Fri Aug 22 09:09:53 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 22 Aug 2025 09:09:53 GMT
Subject: RFR: 8365975: Sort share/memory includes
Message-ID: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>

This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.

Passes `tier1`.

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

Commit messages:
 - nn
 - revert
 - sort

Changes: https://git.openjdk.org/jdk/pull/26897/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26897&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365975
  Stats: 23 lines in 14 files changed: 11 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26897/head:pull/26897

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

From duke at openjdk.org  Fri Aug 22 10:01:30 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 22 Aug 2025 10:01:30 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
Message-ID: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>

> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
> 
> Passes `tier1`.

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

  revert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26897/files
  - new: https://git.openjdk.org/jdk/pull/26897/files/f455e15c..dbdcd4aa

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

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

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

From liach at openjdk.org  Fri Aug 22 15:06:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Aug 2025 15:06:46 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v6]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <MlrcnDPAA4pFQwF7vykRD4VsFQVOal21G70Jvp5J39g=.37029289-8725-4b68-90bb-e46219e78e8d@github.com>

> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25

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

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
 - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
   
   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
 - Variable name improvements
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Move other tier 4,5, etc tests to not use ClassReader
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Use classfile api instead of javac setting version
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7e384ee6...a659f538

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/020659f3..a659f538

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

  Stats: 294312 lines in 5181 files changed: 174425 ins; 82083 del; 37804 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

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

From liach at openjdk.org  Fri Aug 22 15:06:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Aug 2025 15:06:47 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v5]
In-Reply-To: <gjp4FJf9yoF5RkVYFlARr2NF-CLI-DH9wcoBS5FNWLY=.2a680fa0-d7a1-48d9-804b-dc9d285478f5@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <gjp4FJf9yoF5RkVYFlARr2NF-CLI-DH9wcoBS5FNWLY=.2a680fa0-d7a1-48d9-804b-dc9d285478f5@github.com>
Message-ID: <oFm8dDwMra2SEnIvwbL2jdssWLw2MeSZR4bulGdky2o=.e0eca2bf-24f2-47ca-98e2-6e938feda356@github.com>

On Thu, 26 Jun 2025 16:11:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

Circled back and renamed confusing variables in this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/25124#issuecomment-3214696304

From ayang at openjdk.org  Fri Aug 22 16:10:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 16:10:58 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

> Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480.

I identified some cases that doesn't follow this. Unclear whether they are intentional.

test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:

> 34:  * @build jdk.test.whitebox.WhiteBox
> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation

Why not `480` in this case?

test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:

> 38:  * @requires vm.cds
> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses

I was expecting `500 * 4 = 2000`, instead of `8000` here.

test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31:

> 29:  * @compile SuspendResume2.java
> 30:  * @run driver jdk.test.lib.FileInstaller . .
> 31:  * @run main/othervm/native/timeout=700

Why `700` instead of `480` in this file?

test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:

> 57: public class DGCDeadLock implements Runnable {
> 58:     final static public int HOLD_TARGET_TIME = 25000;
> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);

Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:

> 58:  * @comment skip running this test on 32 bit VM
> 59:  * @requires vm.bits == "64"
> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest

Why not `480`?

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:

> 32:  * @build com.foobar.Utils
> 33:  *        com.bar.*
> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest

Why not `480`?

test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:

> 47:  * @library /test/lib /test/jdk
> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription

Why not `480`?

test/jdk/tools/jpackage/share/InstallDirTest.java line 69:

> 67:  * @compile -Xlint:all -Werror InstallDirTest.java
> 68:  * @requires (jpackage.test.SQETest != null)
> 69:  * @run main/othervm/timeout=4000 -Xmx512m jdk.jpackage.test.Main

Why more than `4x` in this file?

test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:

> 36: class HangingRemoteAgent extends RemoteExecutionControl {
> 37: 
> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

why not `Utils.TIMEOUT_FACTOR`?

test/langtools/jdk/jshell/UITesting.java line 148:

> 146:     }
> 147: 
> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

Why not `Utils.TIMEOUT_FACTOR`?

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

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3144985957
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294077875
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294085201
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294089550
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294108202
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294110136
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294113670
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294116148
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294119800
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294128741
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294129243

From eastigeevich at openjdk.org  Fri Aug 22 16:32:55 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 22 Aug 2025 16:32:55 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking
In-Reply-To: <wBKmBh0G0nlXzOM7z5L0QJoFT0SKRd50C7CUBs0zf3U=.419dc51c-7363-4485-9463-184006b8cac8@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GLWyCA8GrPm-N1lgLYME_3sCBO1h7cqSMlu6e5PFYFY=.d42ae04f-8da2-4f7c-b576-229f45dee853@github.com>
 <qHdwTBdp0-bWywVQLp75FRfKo1-aCnrw5WHq2xvXyyM=.30a746db-2959-45fd-bff3-d97f00fddef5@github.com>
 <wBKmBh0G0nlXzOM7z5L0QJoFT0SKRd50C7CUBs0zf3U=.419dc51c-7363-4485-9463-184006b8cac8@github.com>
Message-ID: <sWKmFihk-GRUbI4UXSUcrYbRM2QN89EaD9_IySVxywM=.11b178ba-effe-4778-aafc-ff845919c9bf@github.com>

On Fri, 22 Aug 2025 06:42:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> @eastig I am not sure about this one. Can you clarify please how you can be transforming a class that has not yet been linked? If this is possible then it seems to me we are missing a call to ensure linkage.
>> 
>> Hi @dholmes-ora,
>> 
>> I checked what was happening.
>> 
>> The reproducer from JDK-8277444 simplified:
>> - Thread 1 does:
>> 
>> bigClass = Class.forName();
>> consumer.accept(bigClass); // Puts bigClass in QUEUE
>> final Object o = bigClass.getConstructor().newInstance();
>> System.out.println(o.hashCode());
>> 
>> 
>> - Thread 2 does:
>> 
>> final Class<?> aClass = QUEUE.take();
>> Instrumentation.retransformClasses(aClass); 
>> 
>> 
>> `Class.forName` does not link `bigClass`. So an unlinked class is put in a queue. The linking process starts when we start using `bigClass`.
>> Thread 2 gets unlinked `bigClass` from the queue. It can request to retransform  before we start using it and the linking process starts.
>> 
>> So we can have the linking process and the retransforming process running in parallel. There is no synchronization between them. We get a race condition. `bigClass` is big enough to make the linking process running long.
>> 
>> I think `Class.forName` does not do linking intentionally, for performance reasons.
>> 
>> I hope I've got everything correctly from logs and sources.
>
> @eastig Thank you very much for that detailed analysis. An interesting scenario. I still find it somewhat suspect that we can transform an unlinked class and wonder if we should instead ensure it is linked first, rather than trying to coordinate the two pieces of code via the use of the init_lock. ?

@dholmes-ora 

According to 
- https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.3
- https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-5.html#jvms-5.4

they allow flexibility in an implementation of the linking process. If I am correct,  we have a "lazy" linkage strategy in Hotspot. I don't think we want to change anything here. 

`copy_bytecodes` is only used by JVMTI:
- `JvmtiEnv::RetransformClasses`
- `JvmtiEnv::GetBytecodes`

> I still find it somewhat suspect that we can transform an unlinked class and wonder if we should instead ensure it is linked first,

`JvmtiEnv::RetransformClasses` does not need a class to be linked. It needs the initial class file bytes which are the bytes passed to `ClassLoader.defineClass` or `RedefineClasses`. 
`JvmtiEnv::GetBytecodes` returns the bytecodes that implement the method. It's not clear from the JVMTI specification whether the returned bytecodes must be the initial class bytes. The current implementation returns the initial bytecodes the same used in `JvmtiEnv::RetransformClasses`.

As we don't keep the initial bytecodes (do we?), `copy_bytecodes` cannot be called during linking, linking changes bytecodes. It can only be called for a class in the unlinked and linked states. When `copy_bytecodes` is called for a linked class, it restores bytecodes to the initial ones. Linking cannot be done whilst `copy_bytecodes` is working.

If we use `init_lock`, `copy_bytecodes` will never see a class in the linking state. Linking will never see `copy_bytecodes`. As linking is blocked while we are copying bytecodes, the linking time will increase. This might have negative performance impact. Retrasforming obsoletes an original version of a method, if a new version of the method is installed. So we might not notice the performance impact.

What other options do we have which don't require many changes? We have two mutually exclusive processes.

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

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

From prr at openjdk.org  Fri Aug 22 17:20:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 17:20:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

I don't agree.
If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

I am also questioning whether such a time out was demonstrated for this test.
I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
I can send you my query off-line so you can check it. Maybe it is incomplete.

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

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

From ayang at openjdk.org  Fri Aug 22 18:45:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 18:45:53 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> or don't do it.

Adding `/timeout=480` is more or less don't do anything.

The default timeout (if omitting `/timeout=...`) is 120, so:

master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

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

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

From dlong at openjdk.org  Fri Aug 22 20:30:52 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 22 Aug 2025 20:30:52 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v2]
In-Reply-To: <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
Message-ID: <jGAS1sYq4Hrv-D9c50NdfrU15q-OUYUFVxeAwDGq_pY=.dcb8dd42-9080-4e2a-90ea-5589eee8554a@github.com>

On Wed, 20 Aug 2025 17:31:22 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing include runtime/synchronizer.hpp

This seems like the correct fix.  Forcing these APIs to link the class first would be a change in behavior and I assume it could cause linking-related exceptions to be thrown that the client might not expect.

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

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

From alanb at openjdk.org  Sun Aug 24 09:58:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 24 Aug 2025 09:58:52 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
 <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
Message-ID: <VveE9LwNHbACMKjKW97dxBek0d1JtVSmaLzxJ1d_gKg=.ebe2da86-b1c5-4ca5-890b-693ddbb1dac7@github.com>

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

>>> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.
>> 
>> I don't agree.
>> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.
>> 
>> I am also questioning whether such a time out was demonstrated for this test.
>> I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
>> I can send you my query off-line so you can check it. Maybe it is incomplete.
>
>> or don't do it.
> 
> Adding `/timeout=480` is more or less don't do anything.
> 
> The default timeout (if omitting `/timeout=...`) is 120, so:
> 
> master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
> patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

There are several comments in this PR pointing out again and again that adding "/timeout=480" doesn't change anything with the new proposed default timeout and timeoutFactor. I was initially puzzled as to why these were being added to a lot of tests but I think Leo's runs with a timeoutFactor of 0.7 explains it. If the timeoutFactor is reduced then we risk timeouts from tests that are run close to the limit today. The method used to find these tests seems reasonable. So I think the approach is good and we should try to help him get this change integrated to avoid needing to keep it up to date while tests change in main line.

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

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

From dholmes at openjdk.org  Sun Aug 24 22:54:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 24 Aug 2025 22:54:03 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>

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

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:
> 
>> 34:  * @build jdk.test.whitebox.WhiteBox
>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation
> 
> Why not `480` in this case?

Leo also states in the description:

> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

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

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

From dholmes at openjdk.org  Mon Aug 25 05:50:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 25 Aug 2025 05:50:51 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v2]
In-Reply-To: <jGAS1sYq4Hrv-D9c50NdfrU15q-OUYUFVxeAwDGq_pY=.dcb8dd42-9080-4e2a-90ea-5589eee8554a@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
 <jGAS1sYq4Hrv-D9c50NdfrU15q-OUYUFVxeAwDGq_pY=.dcb8dd42-9080-4e2a-90ea-5589eee8554a@github.com>
Message-ID: <_1EITTUXnsot8Cmplf_3ZBhDi7kpqzXyHZM_GrdF5u8=.dc770146-6eed-4a6b-8729-ce5ab5030ffd@github.com>

On Fri, 22 Aug 2025 20:28:08 GMT, Dean Long <dlong at openjdk.org> wrote:

> This seems like the correct fix. Forcing these APIs to link the class first would be a change in behavior and I assume it could cause linking-related exceptions to be thrown that the client might not expect.

@dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`.

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

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

From dholmes at openjdk.org  Mon Aug 25 06:46:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 25 Aug 2025 06:46:56 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking
In-Reply-To: <qHdwTBdp0-bWywVQLp75FRfKo1-aCnrw5WHq2xvXyyM=.30a746db-2959-45fd-bff3-d97f00fddef5@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GLWyCA8GrPm-N1lgLYME_3sCBO1h7cqSMlu6e5PFYFY=.d42ae04f-8da2-4f7c-b576-229f45dee853@github.com>
 <qHdwTBdp0-bWywVQLp75FRfKo1-aCnrw5WHq2xvXyyM=.30a746db-2959-45fd-bff3-d97f00fddef5@github.com>
Message-ID: <ysx2yM6b3D8gFlo2mLaWaeX6i_adpvYA9n8iyare_cg=.b6240100-1e90-4bdd-9acf-a34b87f21621@github.com>

On Thu, 21 Aug 2025 23:34:13 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> Class.forName does not link bigClass. 

Just to be clear `Class.forName(name, false, loader)` would not initialize the class; the default form would initialize and thus link the class. The `Class.forName` spec does not state whether or not it actually performs full linking in the absence of initialization, though the hotspot implementation does not. Note that the preparation phase of linking must have occurred to get the Class object.

The retransformation API's are somewhat vague about the exact state of a class to be retransformed - the class must be "modifiable" but that seems to be treated as a static rather than dynamic property ie. primitives, arrays, hidden classes are not modifiable - any other type of class instance is.

Bottom line is that I don't think any of the specifications help us here, so we need to look at implementation practicalities.

The linking code, uses the `init_lock` and assumes it cannot be interfered with in any way. I don't know either pieces of code well enough to say whether we could devise a lock-free protocol that would handle the current case; or whether we could use a VM mutex around the critical part of the linking code?

I don't like JVM TI having to know anything about the `init_lock` and I don't like seeing another place where we acquire the `init_lock` via an `ObjectLocker`, as that does not play nicely with the work to avoid pinning for virtual threads.

I'd like to hear from others more knowledgeable than myself in this area, unfortunately @coleenp  is on vacation and won't be back till next week.

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

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

From dholmes at openjdk.org  Mon Aug 25 07:09:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 25 Aug 2025 07:09:02 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
Message-ID: <S8FUiC8e3Ef-uaOpHXIG3CAp1OTo4KIPiW7cFQ83f5I=.1944c558-a1af-438f-a345-49dc6a074651@github.com>

On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

Thanks for the Review Kim!

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3219089008

From dholmes at openjdk.org  Mon Aug 25 07:09:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 25 Aug 2025 07:09:02 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <qqr1wCRNhu-dnJWGmqNiJpokOR6i23eHaH84qRjNFBw=.0cf37006-2bb8-4509-99c1-3b0db4ed39f0@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
 <idaZ8CjLSYTU2tp0vkAjZ080E3dWoqPxKVIH8Obw9yk=.89f5598c-8591-4bf0-9d51-88151051c608@github.com>
 <qqr1wCRNhu-dnJWGmqNiJpokOR6i23eHaH84qRjNFBw=.0cf37006-2bb8-4509-99c1-3b0db4ed39f0@github.com>
Message-ID: <r1iIIS35vODae4TPbXtIFD0l4ysCBaRFIATvgogjeNc=.8be48bfb-52be-48da-b965-33fce3c26742@github.com>

On Thu, 21 Aug 2025 07:46:18 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Yes but again if that happens during testing we need to know and fix the buffer size to get the non-truncated values.
>
> In this case the buffer size comes from shared code.  Whatever size we choose for the static buffer, we can trigger the assert by setting LIBPATH and LD_LIBRARY_PATH to very long strings.  This is just the error message, so it might be OK to truncate it.  Otherwise we could need to allocate the buffer using malloc.

I'm inclined to keep the assert and address any future problems if they arise. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2297294080

From shade at openjdk.org  Mon Aug 25 09:06:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 25 Aug 2025 09:06:54 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <T8xdUGt3ARNffwXh20b-umS9c3NVEQyGFsRCgLR_6Ko=.ff394d2c-f0f3-41ad-b320-00f32d8c3860@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

This looks good to me. Someone from Runtime team should also take a look.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26897#pullrequestreview-3150532402

From sroy at openjdk.org  Mon Aug 25 09:30:56 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 25 Aug 2025 09:30:56 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: <pirpK_avi2C6QJi2mqtu4zUiFZ7EJQ4cBwivhmIoG-Q=.d4e8028d-85f6-4b9d-939c-479b3e12d316@github.com>

On Thu, 7 Aug 2025 06:01:12 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 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().

@tstuefe  You mean the first load calculated would be -1 and that would be an issue ? or is it about finding the right delta between measurements ?

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

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

From lkorinth at openjdk.org  Mon Aug 25 10:52:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 10:52:01 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>
Message-ID: <AFdpOMl_1ooSkxayT06rLAB2YAqOdpOVArSwLFhr5RI=.9ad37969-d90c-44e8-8839-2efb60f9f0a0@github.com>

On Sun, 24 Aug 2025 22:51:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:
>> 
>>> 34:  * @build jdk.test.whitebox.WhiteBox
>>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>>> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation
>> 
>> Why not `480` in this case?
>
> Leo also states in the description:
> 
>> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

In a few places, I have got timeouts after adjusting the timeout value. This is most likely because I have used a timeout factor of 0.7 to minimise "flickering" behaviour before finally changing to a timeout factor of 1. One consequence of this is that a few test cases will have double the original timeout (those test that would not pass a reduction to 0.7). So in all the instances when the timeout factor is exactly two times the size, the reason is that I have realised that I have already adjusted the timeout and I do not want to quad it again.

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

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

From lkorinth at openjdk.org  Mon Aug 25 10:52:09 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 10:52:09 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <vSDcN6CwSbjugZPSWSankLFy31FA2rVoSuJidKO-yLQ=.e2955c07-efad-498c-9606-cb9ab46ed327@github.com>

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

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:
> 
>> 38:  * @requires vm.cds
>> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
>> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses
> 
> I was expecting `500 * 4 = 2000`, instead of `8000` here.

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:
> 
>> 58:  * @comment skip running this test on 32 bit VM
>> 59:  * @requires vm.bits == "64"
>> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:
> 
>> 32:  * @build com.foobar.Utils
>> 33:  *        com.bar.*
>> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:
> 
>> 47:  * @library /test/lib /test/jdk
>> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
>> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297768577
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773391
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773648
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297774209

From lkorinth at openjdk.org  Mon Aug 25 11:04:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:04:00 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <nlwJNUKGatY6Irnw2NlsOMfSpPv_kE_dY8mY_cggDy8=.5136bc97-670f-4b23-bbf5-6277ddd7de3d@github.com>

On Fri, 22 Aug 2025 16:06:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:
> 
>> 36: class HangingRemoteAgent extends RemoteExecutionControl {
>> 37: 
>> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));
> 
> why not `Utils.TIMEOUT_FACTOR`?

There are a few places where I have changed java files that are not jtreg tests themself. The code is used by a jtreg test, but is not the "entry" into a test. Those files have no way to specify `@library` annotations, as no "test annotations" are parsed. It is a pity that a jtreg "library" can not specify dependencies to other "libraries".

> test/langtools/jdk/jshell/UITesting.java line 148:
> 
>> 146:     }
>> 147: 
>> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));
> 
> Why not `Utils.TIMEOUT_FACTOR`?

[see above](https://github.com/openjdk/jdk/pull/26749#discussion_r2297800775)

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

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

From lkorinth at openjdk.org  Mon Aug 25 11:19:53 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:19:53 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <cORbSIzlWv8wgHca57OZ7Mm1wGDOGrYFEoUvNKLjcU0=.00ee4953-8c94-4812-89a5-f710dbe570d1@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

I am awaiting Oracle internal feedback if you wonder why I have still not updated copyright and integrated.  Target date for integration is second of September.

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

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

From lkorinth at openjdk.org  Mon Aug 25 11:43:54 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:43:54 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>

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

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:
> 
>> 57: public class DGCDeadLock implements Runnable {
>> 58:     final static public int HOLD_TARGET_TIME = 25000;
>> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);
> 
> Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4).

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

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

From ayang at openjdk.org  Mon Aug 25 13:50:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 25 Aug 2025 13:50:55 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
Message-ID: <plR6IBqt_CP-kbXrzVRQ-ZHQcmVAxFFHDkeXOA-fM5M=.0facc4e4-3564-42d5-978e-8173723f8d07@github.com>

On Mon, 25 Aug 2025 11:40:56 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> while not multiplying a 10x factor with four resulting in a 40x factor.

Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000)  * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO.

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

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

From mbaesken at openjdk.org  Mon Aug 25 17:16:47 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 25 Aug 2025 17:16:47 GMT
Subject: RFR: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
In-Reply-To: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
References: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
Message-ID: <Y5h24X2EmP5PENredq56AYqOwKX8IkMH1NsCr0PyUeI=.937b47f4-506f-4c40-95d4-8b14aa8b5c72@github.com>

On Tue, 19 Aug 2025 14:18:15 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> The fix for [JDK-8279005](https://bugs.openjdk.org/browse/JDK-8279005) also fixed [JDK-8248691](https://bugs.openjdk.org/browse/JDK-8248691) and [JDK-8268211](https://bugs.openjdk.org/browse/JDK-8268211), which latter two are closed as dups. So, I've removed all jstatLineCountsX.sh from the ProblemList. I propose this patch is trivial.

Marked as reviewed by mbaesken (Reviewer).

No issues were observed so far in our tests, so this looks okay to me.

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

PR Review: https://git.openjdk.org/jdk/pull/26844#pullrequestreview-3152368794
PR Comment: https://git.openjdk.org/jdk/pull/26844#issuecomment-3221087493

From phh at openjdk.org  Mon Aug 25 19:37:42 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 25 Aug 2025 19:37:42 GMT
Subject: RFR: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
In-Reply-To: <Y5h24X2EmP5PENredq56AYqOwKX8IkMH1NsCr0PyUeI=.937b47f4-506f-4c40-95d4-8b14aa8b5c72@github.com>
References: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
 <Y5h24X2EmP5PENredq56AYqOwKX8IkMH1NsCr0PyUeI=.937b47f4-506f-4c40-95d4-8b14aa8b5c72@github.com>
Message-ID: <Uq7ht8R1y61r3tb0tghlZWrruq8dzNH0q66LzS99ooo=.4f550307-67ce-4648-ad64-1de141f57359@github.com>

On Mon, 25 Aug 2025 17:14:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The fix for [JDK-8279005](https://bugs.openjdk.org/browse/JDK-8279005) also fixed [JDK-8248691](https://bugs.openjdk.org/browse/JDK-8248691) and [JDK-8268211](https://bugs.openjdk.org/browse/JDK-8268211), which latter two are closed as dups. So, I've removed all jstatLineCountsX.sh from the ProblemList. I propose this patch is trivial.
>
> No issues were observed so far in our tests, so this looks okay to me.

Thanks, @MBaesken, integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/26844#issuecomment-3221499828

From phh at openjdk.org  Mon Aug 25 19:37:42 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 25 Aug 2025 19:37:42 GMT
Subject: Integrated: 8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from
 ProblemList on linux-ppc64le and aix due to JDK-8248691
In-Reply-To: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
References: <3UoggSo2bIhTnBqUbY8ERDM0MszvY0V8qaZJhrWRtF4=.b5f4a9b3-c55c-4ac4-b39e-7aed36cd6bda@github.com>
Message-ID: <IwIeo86B88Kkb6LnwyWTxyJbZ4h02MmeqEWB2QJ4TEQ=.d3b617db-f019-42a2-8a8f-b5b6cb999e06@github.com>

On Tue, 19 Aug 2025 14:18:15 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> The fix for [JDK-8279005](https://bugs.openjdk.org/browse/JDK-8279005) also fixed [JDK-8248691](https://bugs.openjdk.org/browse/JDK-8248691) and [JDK-8268211](https://bugs.openjdk.org/browse/JDK-8268211), which latter two are closed as dups. So, I've removed all jstatLineCountsX.sh from the ProblemList. I propose this patch is trivial.

This pull request has now been integrated.

Changeset: 1a7ac16d
Author:    Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a7ac16d239cc1c244955a32baa8f5b32367790d
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8364382: Remove sun/tools/jstat/jstatLineCountsX.sh from ProblemList on linux-ppc64le and aix due to JDK-8248691

Reviewed-by: eastigeevich, cjplummer, mbaesken

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

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

From dholmes at openjdk.org  Mon Aug 25 20:26:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 25 Aug 2025 20:26:40 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v2]
In-Reply-To: <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
Message-ID: <EmuB790ii76mPABqeh4W11nSbRWjZ80QJlChuwT8enw=.504ea5e8-6910-4596-8824-73fac6d8df92@github.com>

On Wed, 20 Aug 2025 17:31:22 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing include runtime/synchronizer.hpp

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

> 1002:   // is_rewritten() returns false. So we won't restore the original bytecodes.
> 1003:   // We hold a lock to guarantee we are not getting bytecodes
> 1004:   // at the same time the linking process are rewriting them.

Suggestion:

  // We acquire the init_lock monitor to serialize with class linking so we are not getting 
  // bytecodes at the same time the linking process is rewriting them.

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

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

From dholmes at openjdk.org  Mon Aug 25 20:30:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 25 Aug 2025 20:30:35 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v2]
In-Reply-To: <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
Message-ID: <IcTKivNYQHW4Nse0TWuDja1lCHlLDfAlB5xqZMjOtP0=.c821b348-713e-4b6c-8136-3b674407f9aa@github.com>

On Wed, 20 Aug 2025 17:31:22 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing include runtime/synchronizer.hpp

I've heard from Coleen and she seems okay with this approach; and Patricio doesn't think it will have an impact on the virtual thread work - so that eases my concerns. I have some minor requested changes whilst we wait for a serviceability review.

Thanks

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

> 1004:   // at the same time the linking process are rewriting them.
> 1005:   Handle h_init_lock(Thread::current(), mh->method_holder()->init_lock());
> 1006:   ObjectLocker ol(h_init_lock, JavaThread::current());

Suggestion:

  JavaThread* current = JavaThread::current();
  Handle h_init_lock(current, mh->method_holder()->init_lock());
  ObjectLocker ol(h_init_lock, current);

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3152910901
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2299048252

From dlong at openjdk.org  Mon Aug 25 21:14:34 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 25 Aug 2025 21:14:34 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v2]
In-Reply-To: <jGAS1sYq4Hrv-D9c50NdfrU15q-OUYUFVxeAwDGq_pY=.dcb8dd42-9080-4e2a-90ea-5589eee8554a@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
 <jGAS1sYq4Hrv-D9c50NdfrU15q-OUYUFVxeAwDGq_pY=.dcb8dd42-9080-4e2a-90ea-5589eee8554a@github.com>
Message-ID: <fstPeItn2K0x1nyiXFp51OsoViouKoYfLqMZG35-k4A=.0b7894ff-87cf-420d-85c7-b5494a081398@github.com>

On Fri, 22 Aug 2025 20:28:08 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing include runtime/synchronizer.hpp
>
> This seems like the correct fix.  Forcing these APIs to link the class first would be a change in behavior and I assume it could cause linking-related exceptions to be thrown that the client might not expect.

> @dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`.

I see that in java.lang.instrument, but the JVMTI spec says "In response to this call, no events other than the ClassFileLoadHook event will be sent."  Normally during linking we send the ClassPrepare event.

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

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

From dholmes at openjdk.org  Tue Aug 26 04:53:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 26 Aug 2025 04:53:39 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v2]
In-Reply-To: <fstPeItn2K0x1nyiXFp51OsoViouKoYfLqMZG35-k4A=.0b7894ff-87cf-420d-85c7-b5494a081398@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
 <jGAS1sYq4Hrv-D9c50NdfrU15q-OUYUFVxeAwDGq_pY=.dcb8dd42-9080-4e2a-90ea-5589eee8554a@github.com>
 <fstPeItn2K0x1nyiXFp51OsoViouKoYfLqMZG35-k4A=.0b7894ff-87cf-420d-85c7-b5494a081398@github.com>
Message-ID: <L5hQIlvzYcr-0GThwb_uGAzusmaZftA7wkED_Y-iMKQ=.2189092b-e962-47c2-af87-dfe3b20636c1@github.com>

On Mon, 25 Aug 2025 21:11:34 GMT, Dean Long <dlong at openjdk.org> wrote:

> > @dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`.
> 
> I see that in java.lang.instrument, but the JVMTI spec says "In response to this call, no events other than the ClassFileLoadHook event will be sent." Normally during linking we send the ClassPrepare event.

To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror).

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

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

From fbredberg at openjdk.org  Tue Aug 26 09:41:38 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 26 Aug 2025 09:41:38 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
Message-ID: <fU9pGo2GqB_clYfAihitW7kH983r6i5GJko0FIUTBDQ=.d48c852b-8de0-47d8-a96d-d69dd7353c1b@github.com>

On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

A good looking PR, and a good step in the right direction. Nice!

But as @kimbarrett I also noticed there are a number of calls with `buflen - 1`, which in my case consumed too mush of the review time. So it would be nice to see a follow up that deals with code like [this](https://github.com/openjdk/jdk/blob/38003a227a55dbd6adb89dcb10dc619f08bb0187/src/hotspot/os/bsd/os_bsd.cpp#L2493).

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

Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26849#pullrequestreview-3154824577

From ayang at openjdk.org  Tue Aug 26 10:59:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 26 Aug 2025 10:59:36 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <WoXAKfA8CUSIppfvHFsN7V1ZXEXGVl_iQ3Zl9q8eYTM=.9fcb62ca-8ce4-43a9-97d4-fcf472255e89@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26897#pullrequestreview-3155082295

From duke at openjdk.org  Tue Aug 26 10:59:36 2025
From: duke at openjdk.org (duke)
Date: Tue, 26 Aug 2025 10:59:36 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <3WbMaXl0VfekG7xSWpfrikxjrsugqUEG6jQM1DkqiM8=.47a884c8-e336-4ae8-93bd-cd4892f2defd@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

@fandreuz 
Your change (at version dbdcd4aa1778fda464f8c553ef3cc4bc4a14854c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26897#issuecomment-3223675874

From jwaters at openjdk.org  Tue Aug 26 12:34:39 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 26 Aug 2025 12:34:39 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <hlW5KXHMaFEnNPBWMbUqNH0FXgChZELc1sCxLujS49Q=.e16c6a0b-c6dd-4d2e-a150-8821cd16b9df@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

I've never actually used the include sorting tool before. I see that it (SortIncludes.java) lives under jtreg, a strange place for a utility tool. Is it invoked automatically as part of the build process, or does one invoke it manually only when it's desired to sort includes of source files in a given directory? If it's the latter, it might be more suitable to be in src/utils instead. I digress, just thinking out loud here. The change itself is fine.

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26897#pullrequestreview-3155421239

From stefank at openjdk.org  Tue Aug 26 12:48:40 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 26 Aug 2025 12:48:40 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <vRjtRUhAKf2_1MmXpELZGt4JpZKdozHLWj65SzDY5gk=.5958ee23-673d-4686-bb74-ae3f75dd47dd@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

FWIW, I had similar thoughts about the location of the tool when it was introduced:
https://mail.openjdk.org/pipermail/hotspot-dev/2025-March/103078.html

But I think I was in minority w.r.t. that when I asked around.

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

PR Comment: https://git.openjdk.org/jdk/pull/26897#issuecomment-3224034035

From eastigeevich at openjdk.org  Tue Aug 26 13:39:14 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 26 Aug 2025 13:39:14 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
Message-ID: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>

> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
> 
> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
> 
> Tested fastdebug and release builds: Linux x86_64 and arm64
> - The reproducer from JDK-8277444 passed.
> - Tier1 - tier3 passed.

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

  Symplify comments; Get JavaThread::current in variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26863/files
  - new: https://git.openjdk.org/jdk/pull/26863/files/d6895181..293d81ff

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

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

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

From eastigeevich at openjdk.org  Tue Aug 26 13:39:14 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 26 Aug 2025 13:39:14 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v2]
In-Reply-To: <L5hQIlvzYcr-0GThwb_uGAzusmaZftA7wkED_Y-iMKQ=.2189092b-e962-47c2-af87-dfe3b20636c1@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
 <jGAS1sYq4Hrv-D9c50NdfrU15q-OUYUFVxeAwDGq_pY=.dcb8dd42-9080-4e2a-90ea-5589eee8554a@github.com>
 <fstPeItn2K0x1nyiXFp51OsoViouKoYfLqMZG35-k4A=.0b7894ff-87cf-420d-85c7-b5494a081398@github.com>
 <L5hQIlvzYcr-0GThwb_uGAzusmaZftA7wkED_Y-iMKQ=.2189092b-e962-47c2-af87-dfe3b20636c1@github.com>
Message-ID: <iCYq0rSMTPsy7ClbWDlFuF5RfJphoBj7tUFH2fZe4C4=.1bfbb881-659c-403a-9b25-1e67fe394ab4@github.com>

On Tue, 26 Aug 2025 04:50:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> @dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`.
>> 
>> I see that in java.lang.instrument, but the JVMTI spec says "In response to this call, no events other than the ClassFileLoadHook event will be sent."  Normally during linking we send the ClassPrepare event.
>
>> > @dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`.
>> 
>> I see that in java.lang.instrument, but the JVMTI spec says "In response to this call, no events other than the ClassFileLoadHook event will be sent." Normally during linking we send the ClassPrepare event.
> 
> To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror).

@dholmes-ora Thank you for review and the suggestions.

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

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

From eastigeevich at openjdk.org  Tue Aug 26 13:39:14 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 26 Aug 2025 13:39:14 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v2]
In-Reply-To: <EmuB790ii76mPABqeh4W11nSbRWjZ80QJlChuwT8enw=.504ea5e8-6910-4596-8824-73fac6d8df92@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <iVkvL0uRGMqWdCkR1FHQiuEY1Kb1TVbqh6uPP3cItiU=.2be7b02d-4743-4dc4-9dcd-c650439bfc79@github.com>
 <EmuB790ii76mPABqeh4W11nSbRWjZ80QJlChuwT8enw=.504ea5e8-6910-4596-8824-73fac6d8df92@github.com>
Message-ID: <vbOi9hdWvID8xtVK-pr1sRtdbCDxJbfwBk_lvWrERmw=.13039cb0-a003-4c67-98d5-4966023e11b8@github.com>

On Mon, 25 Aug 2025 20:23:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing include runtime/synchronizer.hpp
>
> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 1004:
> 
>> 1002:   // is_rewritten() returns false. So we won't restore the original bytecodes.
>> 1003:   // We hold a lock to guarantee we are not getting bytecodes
>> 1004:   // at the same time the linking process are rewriting them.
> 
> Suggestion:
> 
>   // We acquire the init_lock monitor to serialize with class linking so we are not getting 
>   // bytecodes at the same time the linking process is rewriting them.

Done

> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 1006:
> 
>> 1004:   // at the same time the linking process are rewriting them.
>> 1005:   Handle h_init_lock(Thread::current(), mh->method_holder()->init_lock());
>> 1006:   ObjectLocker ol(h_init_lock, JavaThread::current());
> 
> Suggestion:
> 
>   JavaThread* current = JavaThread::current();
>   Handle h_init_lock(current, mh->method_holder()->init_lock());
>   ObjectLocker ol(h_init_lock, current);

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2301024352
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2301023827

From mdonovan at openjdk.org  Tue Aug 26 17:08:38 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 26 Aug 2025 17:08:38 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/sun/security/krb5/name/Constructors.java line 28:

> 26:  * @summary Make PrincipalName and Realm immutable
> 27:  * @modules java.security.jgss/sun.security.krb5
> 28:  * @run main/othervm Constructors

Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second.

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

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

From dlong at openjdk.org  Tue Aug 26 20:56:36 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 26 Aug 2025 20:56:36 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

(I realize this is a tangent, but maybe there is a separate bug here...)

> To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror).

If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced:

https://github.com/openjdk/jdk/blob/c75534517729b903b63263cf64dc2ff841e3dcb1/src/hotspot/share/oops/instanceKlass.cpp#L1064

Class.forName(name, false, loader) would result in a prepared class but without the event being sent.

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

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

From amenkov at openjdk.org  Tue Aug 26 21:36:36 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 26 Aug 2025 21:36:36 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <49qk6MM99RlDuhksM3pPOjGXWm6fy8av7JPoAn4N2n8=.729ed685-2abd-4571-bc83-a421f026fde5@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

The fix looks good from serviceability perspective

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

Marked as reviewed by amenkov (Reviewer).

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

From dholmes at openjdk.org  Wed Aug 27 06:40:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 27 Aug 2025 06:40:47 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com>
Message-ID: <F5wBMFVi24FTOoSB4vcbDoWTlsw2NeZo7ZDITNRE_vA=.5db8a8e8-d251-40af-8287-51092f871503@github.com>

On Tue, 26 Aug 2025 20:53:57 GMT, Dean Long <dlong at openjdk.org> wrote:

> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced

@dean-long it seems the JVM TI "prepare" event is somewhat misnamed. It states "At this point, class fields, methods, and implemented interfaces are available, and no code from the class has been executed." but that neither describes preparation, nor the rest of linking. You can only access fields and methods after a class has been initialized! But lets take this elsewhere if needed.

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

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

From dholmes at openjdk.org  Wed Aug 27 06:50:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 27 Aug 2025 06:50:44 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <fU9pGo2GqB_clYfAihitW7kH983r6i5GJko0FIUTBDQ=.d48c852b-8de0-47d8-a96d-d69dd7353c1b@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
 <fU9pGo2GqB_clYfAihitW7kH983r6i5GJko0FIUTBDQ=.d48c852b-8de0-47d8-a96d-d69dd7353c1b@github.com>
Message-ID: <V_X0D3tF1DpMHR56dBCA3hRXnDMKnRjBQdUIj9tG0ew=.2eac103c-da3e-4a67-b3dc-9cbfca39993d@github.com>

On Tue, 26 Aug 2025 09:38:54 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reviewer feedback
>
> A good looking PR, and a good step in the right direction. Nice!
> 
> But as @kimbarrett I also noticed there are a number of calls with `buflen - 1`, which in my case consumed too mush of the review time. So it would be nice to see a follow up that deals with code like [this](https://github.com/openjdk/jdk/blob/38003a227a55dbd6adb89dcb10dc619f08bb0187/src/hotspot/os/bsd/os_bsd.cpp#L2493).

Thanks for the review @fbredber . I have added your cleanup suggestion to [JDK-8365896](https://bugs.openjdk.org/browse/JDK-8365896) as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3226972822

From eastigeevich at openjdk.org  Wed Aug 27 11:20:42 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 11:20:42 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <N_n8r4AGEpxI3IPjBYu16h-O4zbuNMb0tv2Fuo8-zss=.8d6302a1-58cf-424e-a88a-adf6aa961920@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

MacOS test failures are known:
- https://bugs.openjdk.org/browse/JDK-8344577
- https://bugs.openjdk.org/browse/JDK-8215245

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

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

From eastigeevich at openjdk.org  Wed Aug 27 11:23:44 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 11:23:44 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <F5wBMFVi24FTOoSB4vcbDoWTlsw2NeZo7ZDITNRE_vA=.5db8a8e8-d251-40af-8287-51092f871503@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com>
 <F5wBMFVi24FTOoSB4vcbDoWTlsw2NeZo7ZDITNRE_vA=.5db8a8e8-d251-40af-8287-51092f871503@github.com>
Message-ID: <1p2Lq9aw48jkG5BjxHT0GrrJ-94WkPZ77YMBaARuxf4=.8795152e-d3f0-421a-8cc3-ee075cfa6d2d@github.com>

On Wed, 27 Aug 2025 06:37:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> (I realize this is a tangent, but maybe there is a separate bug here...)
>> 
>>> To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror).
>> 
>> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced:
>> 
>> https://github.com/openjdk/jdk/blob/c75534517729b903b63263cf64dc2ff841e3dcb1/src/hotspot/share/oops/instanceKlass.cpp#L1064
>> 
>> Class.forName(name, false, loader) would result in a prepared class but without the event being sent.
>
>> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced
> 
> @dean-long it seems the JVM TI "prepare" event is somewhat misnamed. It states "At this point, class fields, methods, and implemented interfaces are available, and no code from the class has been executed." but that neither describes preparation, nor the rest of linking. You can only access fields and methods after a class has been initialized! But lets take this elsewhere if needed.

Hi @dholmes-ora,
Are there any other action items/changes required?

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

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

From jpai at openjdk.org  Wed Aug 27 11:30:44 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 27 Aug 2025 11:30:44 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <N_n8r4AGEpxI3IPjBYu16h-O4zbuNMb0tv2Fuo8-zss=.8d6302a1-58cf-424e-a88a-adf6aa961920@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <N_n8r4AGEpxI3IPjBYu16h-O4zbuNMb0tv2Fuo8-zss=.8d6302a1-58cf-424e-a88a-adf6aa961920@github.com>
Message-ID: <jC4aSiI2NYPS-y9OWhwZq9g27b_4swIzLC4bq4JG41U=.13950b23-3824-45ee-ba8f-8e8c5e2a6891@github.com>

On Wed, 27 Aug 2025 11:17:50 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> MacOS test failures are known

The virtual thread test that is failing in this PR's GitHub actions job is `java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking#id0` It has this:


javatestOS=Mac OS X 14.7.6 (aarch64)
javatestVersion=6.0-ea+b24-2025-08-18-${BUILT_FROM_COMMIT}
jtregVersion=jtreg 7.5.2 dev 0
...
#section:main
----------messages:(10/424)----------
command: main GetStackTraceALotWhenBlocking 100000
reason: User specified action: run main/othervm/timeout=300 GetStackTraceALotWhenBlocking 100000 
started: Tue Aug 26 14:24:40 UTC 2025
Mode: othervm [/othervm specified]
Additional options from @modules: --add-modules jdk.management
Process id: 21219
Timeout information:
--- Timeout information end.
finished: Tue Aug 26 14:47:22 UTC 2025
elapsed time (seconds): 1361.83
----------configuration:(3/42)----------
Boot Layer
  add modules: jdk.management

----------System.out:(1190/56017)----------
2025-08-26T14:24:41.601528Z => 48 of 100000
...
2025-08-26T14:44:37.436452Z => 99703 of 100000
2025-08-26T14:44:38.451885Z => 99752 of 100000
2025-08-26T14:44:39.474953Z => 99787 of 100000
Timeout signalled after 1200 seconds
2025-08-26T14:44:40.477403Z => 99833 of 100000
2025-08-26T14:44:41.478976Z => 99886 of 100000
2025-08-26T14:44:42.487173Z => 99931 of 100000
2025-08-26T14:44:43.495950Z => 99975 of 100000
2025-08-26T14:44:44.055060Z => 100000 of 100000
2025-08-26T14:44:44.055248Z VirtualThread[#27]/runnable at ForkJoinPool-1-worker-3 => 3904532796 loops
2025-08-26T14:44:44.055381Z VirtualThread[#23]/runnable at ForkJoinPool-1-worker-1 => 3293339644 loops
----------System.err:(1/15)----------
STATUS:Passed.
...
test result: Error. Program `/Users/runner/work/jdk/jdk/bundles/jdk/jdk-26.jdk/Contents/Home/bin/java' timed out (timeout set to 1200000ms, elapsed time including timeout handling was 1361819ms).


It looks like it's taking long to complete and that's causing the test timeout. I recollect that this test failure was addressed some time back, so this appears to be a new occurrence. In any case, this failure doesn't look related to the changes in this PR because I see some other PRs having failed with this same issue. I'll check and file an issue later today/tomorrow (unless anyone else gets to it first).

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

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

From coleenp at openjdk.org  Wed Aug 27 13:15:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 13:15:45 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <VXMfu0o6kLLsa61GtF6pOvRqumZHZAO4zJxX9B4hOrM=.71fb2208-1f93-44a2-85b0-e04cb13573cf@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

The problem might be higher in the call stack than here.  I think JvmtiEnv::GetBytecodes should link the class first, rather than have this race.  The bytecode rewriter already restores the bytecodes to their pre-rewritten state when it returns them.  Also, it seems that you would want to only return bytecodes that have been verified, which is also part of linking.

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

Changes requested by coleenp (Reviewer).

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

From eastigeevich at openjdk.org  Wed Aug 27 13:21:50 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 13:21:50 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <VXMfu0o6kLLsa61GtF6pOvRqumZHZAO4zJxX9B4hOrM=.71fb2208-1f93-44a2-85b0-e04cb13573cf@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <VXMfu0o6kLLsa61GtF6pOvRqumZHZAO4zJxX9B4hOrM=.71fb2208-1f93-44a2-85b0-e04cb13573cf@github.com>
Message-ID: <2CINkZVwp01VVT58M9eehT3rziuu52neYgAlDqGNung=.122b252d-7ede-4081-8ef7-d5baae927bc0@github.com>

On Wed, 27 Aug 2025 13:12:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Symplify comments; Get JavaThread::current in variable
>
> The problem might be higher in the call stack than here.  I think JvmtiEnv::GetBytecodes should link the class first, rather than have this race.  The bytecode rewriter already restores the bytecodes to their pre-rewritten state when it returns them.  Also, it seems that you would want to only return bytecodes that have been verified, which is also part of linking.

Hi @coleenp,

> The problem might be higher in the call stack than here. I think JvmtiEnv::GetBytecodes should link the class first, rather than have this race. The bytecode rewriter already restores the bytecodes to their pre-rewritten state when it returns them. Also, it seems that you would want to only return bytecodes that have been verified, which is also part of linking.

Should we have a separate JBS issue to cover `JvmtiEnv::GetBytecodes`?
[JDK-8277444](https://bugs.openjdk.org/browse/JDK-8277444) covers the issue with `JvmtiEnv::RetransformClasses`.

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

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

From coleenp at openjdk.org  Wed Aug 27 13:26:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 13:26:43 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <Dw9E7IKPTaCjjggmsB72B-zQT0ZsvsKe6NdGQvcJhqU=.db128dcb-0f05-4aed-bead-b8ff4c6ad3f3@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

I think both should link the class first.

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

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

From coleenp at openjdk.org  Wed Aug 27 13:31:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 13:31:45 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <NNsBS94PUa8UrhcgslY6aUMc6Z_lXVutnEEnc0FzRDo=.85ac3157-63a2-402b-a32b-ee6b0f35228e@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

Also sorry, I was reviewing this on my phone earlier this week and am just back from being away.

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

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

From eastigeevich at openjdk.org  Wed Aug 27 13:54:46 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 13:54:46 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <Dw9E7IKPTaCjjggmsB72B-zQT0ZsvsKe6NdGQvcJhqU=.db128dcb-0f05-4aed-bead-b8ff4c6ad3f3@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <Dw9E7IKPTaCjjggmsB72B-zQT0ZsvsKe6NdGQvcJhqU=.db128dcb-0f05-4aed-bead-b8ff4c6ad3f3@github.com>
Message-ID: <1KLcFmF-jeGWzU8EETPPY_JTI5Kq36FHIMdnX0FOiAU=.af70c9a2-ac30-46bf-8ce3-e6040d971167@github.com>

On Wed, 27 Aug 2025 13:23:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I think both should link the class first. It's because I don't like the init-lock exposed this way, and I'm concerned with JVMTI getting and saving unverified bytecodes.

In logs I see we do class verification:


[0.962s][debug][class,link              ] JvmtiEnv::RetransformClasses
[0.970s][debug][redefine,class,load     ] loading name=BigClass kind=101 (avail_mem=252818288K)
[0.970s][debug][class,preorder          ] BigClass source: __VM_RedefineClasses__
[0.971s][debug][class,load,placeholders ] entry BigClass : find_and_add DETECT_CIRCULARITY , next_klass_name 'java/lang/Object'
[0.971s][debug][class,load,placeholders ] loadInstanceThreadQ threads:
[0.971s][debug][class,load,placeholders ] circularityThreadQ threads:0x0000ffff903953b0,
[0.971s][debug][class,load,placeholders ] defineThreadQ threads:
[0.971s][debug][class,load,placeholders ] entry BigClass : find_and_remove DETECT_CIRCULARITY , next_klass_name 'java/lang/Object'
[0.971s][debug][class,load,placeholders ] loadInstanceThreadQ threads:
[0.971s][debug][class,load,placeholders ] circularityThreadQ threads:0x0000ffff903953b0,
[0.971s][debug][class,load,placeholders ] defineThreadQ threads:
[0.971s][debug][class,load              ] set_secondary_supers: hash_slot: 45; klass: BigClass
[0.971s][debug][class,load              ]   - 0 elements; bitmap: 0x0000000000000000
[0.973s][info ][class,load              ] BigClass source: __VM_RedefineClasses__
[0.973s][debug][class,load              ]  klass: 0x000000001a088000 super: 0x000000001a001200 loader: [loader data: 0x0000ffff903fc510 for instance a 'Main$AsmClassLoader'{0x00000000ff1a3d28}] bytes: 1403966 checksum: 4f2e199f
[0.973s][debug][class,resolve           ] BigClass java.lang.Object (super)
[0.973s][debug][class,link              ] VM_RedefineClasses::load_new_class_versions 0x000000001a086800
[0.973s][info ][class,init              ] Start class verification for: BigClass
[1.005s][info ][class,init              ] End class verification for: BigClass
[1.005s][debug][class,link              ] rewrite_class 0x000000001a086800
[1.016s][debug][class,link              ] done rewrite_class 0x000000001a086800
[1.016s][info ][class,init              ] Start class verification for: BigClass
[1.048s][info ][class,init              ] End class verification for: BigClass
[1.048s][info ][redefine,class,constantpool] old_cp_len=116, scratch_cp_len=116
[1.048s][debug][redefine,class,constantpool] after pass 0: merge_cp_len=116
[1.048s][debug][redefine,class,constantpool] after pass 1a: merge_cp_len=116, scratch_i=116, index_map_len=0
[1.048s][info ][redefine,class,constantpool] merge_cp_len=116, index_map_len=0
[1.048s][debug][class,loader,data          ] deallocate added for constant pool [232] {0x0000ffff30947748}
[1.059s][debug][redefine,class,load        ] loaded name=BigClass (avail_mem=252817012K)
[1.079s][debug][class,loader,data          ] deallocate added for 'BigClass'
[1.079s][info ][redefine,class,load        ] redefined name=BigClass, count=1 (avail_mem=252817012K)

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

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

From eastigeevich at openjdk.org  Wed Aug 27 14:09:43 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 14:09:43 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <sfmH8plNfGShamGhIx1EMXlz8tMZ3fi24eFVEMApy4g=.09e9ca4b-5bc7-4ace-b44b-98046fd1a43e@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

Looking into `JvmtiEnv::RetransformClasses` code, it does the following:
- Gets the original bytecodes.
- Requests `VM_RedefineClasses` op.

`VM_RedefineClasses` calls `load_new_class_versions()` in `VM_RedefineClasses::doit_prologue`. 

`load_new_class_versions()` does the following:
- Calls `link_class`.
- Calls `Verifier::verify`.

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

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

From eastigeevich at openjdk.org  Wed Aug 27 14:09:43 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 14:09:43 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <NNsBS94PUa8UrhcgslY6aUMc6Z_lXVutnEEnc0FzRDo=.85ac3157-63a2-402b-a32b-ee6b0f35228e@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <NNsBS94PUa8UrhcgslY6aUMc6Z_lXVutnEEnc0FzRDo=.85ac3157-63a2-402b-a32b-ee6b0f35228e@github.com>
Message-ID: <1qCUkGAZTjWhP-Se3s7e5zNx4UXhHCHJZm8qOMMpYNI=.0a5795d0-b6ad-4682-827f-e6e54196bdea@github.com>

On Wed, 27 Aug 2025 13:28:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Symplify comments; Get JavaThread::current in variable
>
> Also sorry, I was reviewing this on my phone earlier this week and am just back from being away.

@coleenp,

> I'm concerned with JVMTI getting and saving unverified bytecodes.

Based on the log and the sources, I don't see how this might happen.

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

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

From mbaesken at openjdk.org  Wed Aug 27 14:30:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 27 Aug 2025 14:30:19 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning: use
 of uninitialized value 'systemTicks'
Message-ID: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>

When using gcc static analyzer (-fanalyzer) with gcc 13.2 the following issue is reported :

/jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c: In function 'get_jvmticks':
/jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c:208:24: warning: use of uninitialized value 'systemTicks' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
  208 | pticks->usedKernel = systemTicks;


vsscanf usually/normally reads the systemTicks info from /proc file system. see
https://github.com/openjdk/jdk/blob/45726a1f8b8f76586037867a32b82f8ab9b96937/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L163
but we never check that the *exact* number of params is read with vsscanf :
n = vsscanf(tmp, fmt, args);
So potentially we could get a non complete info without systemTicks and the call would still succeed.

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

Commit messages:
 - JDK-8366092

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

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

From mbaesken at openjdk.org  Wed Aug 27 14:39:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 27 Aug 2025 14:39:01 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v2]
In-Reply-To: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
Message-ID: <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>

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

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

  init vars so that gcc static analyzer is happy too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26962/files
  - new: https://git.openjdk.org/jdk/pull/26962/files/1e9f0572..cb0f8dfc

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

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

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

From duke at openjdk.org  Wed Aug 27 14:40:50 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 27 Aug 2025 14:40:50 GMT
Subject: Integrated: 8365975: Sort share/memory includes
In-Reply-To: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
Message-ID: <8rJEmCqj9AgxnKKChlDzQFE4lRrrnJJ3JHVYttMNuQE=.5eac4707-a122-45a1-85f9-0108b8ace5b0@github.com>

On Fri, 22 Aug 2025 09:03:45 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
> 
> Passes `tier1`.

This pull request has now been integrated.

Changeset: 79cea6dd
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79cea6dd174c22f99b4cafc835e6c843c1b4ec38
Stats:     22 lines in 13 files changed: 11 ins; 9 del; 2 mod

8365975: Sort share/memory includes

Reviewed-by: shade, ayang, jwaters

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

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

From eastigeevich at openjdk.org  Wed Aug 27 14:57:45 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 14:57:45 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <NNsBS94PUa8UrhcgslY6aUMc6Z_lXVutnEEnc0FzRDo=.85ac3157-63a2-402b-a32b-ee6b0f35228e@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <NNsBS94PUa8UrhcgslY6aUMc6Z_lXVutnEEnc0FzRDo=.85ac3157-63a2-402b-a32b-ee6b0f35228e@github.com>
Message-ID: <bD2TvzzlhhKlXOUc13YUaaAOIJZU3QfEEDF8sIGizLk=.bceeff3a-1d2f-4cc3-9c39-551a1b72b135@github.com>

On Wed, 27 Aug 2025 13:28:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Symplify comments; Get JavaThread::current in variable
>
> Also sorry, I was reviewing this on my phone earlier this week and am just back from being away.

@coleenp,

>  It's because I don't like the init-lock exposed this way

If we don't want to expose the init-lock to JVMTI, we can move `copy_bytecodes` to `InstanceKlass`.
IMO having `InstanceKlass::copy_bytecodes` sounds logical to me. 
Also I think `copy_bytecodes` should use `Rewriter::restore_bytecodes` instead of restoring bytecodes itself.

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

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

From eastigeevich at openjdk.org  Wed Aug 27 15:01:50 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 15:01:50 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <bnM2rv9zCPsDkTyqcUbbWdOwJ5zFeQ-AvcGQa-YC_pI=.7de54c4a-8354-4598-ac75-0ff9a745d938@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

Another thought, we need the fix in 11, 17 and 21, maybe in 8. As the current change is very small, it will be easy to backport it.

Additional enhancements can address 26 only.

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

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

From coleenp at openjdk.org  Wed Aug 27 15:17:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 15:17:44 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <9fG31ThANkObW-DQ3r426pXIGj2DL-aIi34dnFFtcT4=.07336d08-32a2-46b3-877e-01e771876350@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

I don't want this in InstanceKlass.  Let me work on my suggested change.

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

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

From kevinw at openjdk.org  Wed Aug 27 17:46:41 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 27 Aug 2025 17:46:41 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v2]
In-Reply-To: <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
 <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>
Message-ID: <_dzoj_TlgAVspeaYaN5Vaflby5PlodGQ4n3gPXUWIVg=.6933935b-3db2-4430-a5a0-cc44f733dc2b@github.com>

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

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

Yes, seems we have two almost identical read_ticks functions, that's not ideal but hotspot and libmanagement both needed it... Maybe that can be deduplicated in future. 8-)


If we now return when read_ticks doesn't read and set both variables, then the "use of uninitialized value" warning becomes incorrect.

And with the !=2 check it becomes the same as the other usage, in src/hotspot/os/linux/os_perf_linux.cpp

 313 static OSReturn get_jvm_ticks(os::Linux::CPUPerfTicks* pticks) {
 314   uint64_t userTicks;
 315   uint64_t systemTicks;
...
 321   if (read_ticks("/proc/self/stat", &userTicks, &systemTicks) != 2) {
 322     return OS_ERR;
 323   }

...so does that other code have the same analyzer warning?

Ideally I expect we would not change the code just to keep a tool happy, if the warning is not really accurate.... (and presumably the warning might get more accurate in future)

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

PR Review: https://git.openjdk.org/jdk/pull/26962#pullrequestreview-3161078387

From coleenp at openjdk.org  Wed Aug 27 19:30:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 19:30:43 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <3ToXq_Li7f7I0d9-NDZu99y2VeahZaNF2KqS3jIt2_I=.9e625a52-2300-46fc-9f56-b7907c3bfdd5@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

https://github.com/openjdk/jdk/pull/26971

We do link the class during redefinition, when we load the new classfile version.  For the retransformer, we read the classfile from a potentially unlinked class, then link the class after when we do the redefinition/retransformation.  To avoid this race, we can link the bytecodes first, I think then we would not have to redo the linking.  This change is relatively small as well and does not rely on the implementation of what we lock when we link and initialize the class.  I think most of the time, the class is already linked at this stage anyway so it wouldn't have any effect on performance.  I didn't try this on your test yet.

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

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

From eastigeevich at openjdk.org  Wed Aug 27 19:59:43 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 19:59:43 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <3ToXq_Li7f7I0d9-NDZu99y2VeahZaNF2KqS3jIt2_I=.9e625a52-2300-46fc-9f56-b7907c3bfdd5@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <3ToXq_Li7f7I0d9-NDZu99y2VeahZaNF2KqS3jIt2_I=.9e625a52-2300-46fc-9f56-b7907c3bfdd5@github.com>
Message-ID: <wFVCLn8UVBkYv3ribSI8AweObD-Qo5dpckdCBlMI9-g=.a1fb2867-94be-4b2d-8b5c-a97ace72b267@github.com>

On Wed, 27 Aug 2025 19:28:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Symplify comments; Get JavaThread::current in variable
>
> https://github.com/openjdk/jdk/pull/26971
> 
> We do link the class during redefinition, when we load the new classfile version.  For the retransformer, we read the classfile from a potentially unlinked class, then link the class after when we do the redefinition/retransformation.  To avoid this race, we can link the bytecodes first, I think then we would not have to redo the linking.  This change is relatively small as well and does not rely on the implementation of what we lock when we link and initialize the class.  I think most of the time, the class is already linked at this stage anyway so it wouldn't have any effect on performance.  I didn't try this on your test yet.
> 
> This isn't that clear.  Now we do:
> retransform class -> class reconstitutor to get current classfile version -> VM_RedefineClasses -> load class version with this set of bytecodes -> link bytecodes -> etc.
> 
> My change:
> retransform class -> link class -> class reconstitutor to get current classfile version -> etc.

Hi @coleenp,

Thank you for https://github.com/openjdk/jdk/pull/26971.

Don't you mind if we follow the following plan:
1. I pull changes from https://github.com/openjdk/jdk/pull/26971 which fix `RetransformClasses` into this PR.
2. I create a new JBS issues to cover `GetBytecodes`.
3. A separate PR fixing `GetBytecodes` is created.

I'd like to have changes for `RetransformClasses` and `GetBytecodes` be in different PRs to simplify backporting processes. IMO fixing `GetBytecodes` is not critical because it is not available for java agents. Only JVMTI agents can use it. We have not seen any bug reports regarding `GetBytecodes`. Regarding `RetransformClasses` we've got reports of crashing 11, 17 and 21 from different customers.

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

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

From coleenp at openjdk.org  Wed Aug 27 20:09:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 20:09:43 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

You could separate the two if you'd like. I'm running tier1-4 testing on the PR I sent right now. Also, I haven't tried it on your test.
Edit again: I don't see your test added to this PR.

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

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

From eastigeevich at openjdk.org  Wed Aug 27 21:10:43 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 27 Aug 2025 21:10:43 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com>
Message-ID: <4BN2zeKJgyr4Okr4vX2tOqaUGmbYu-g_BmBlwHWcvBI=.e783fcdd-7c30-44ac-bc57-aa658478e170@github.com>

On Wed, 27 Aug 2025 20:05:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I don't see your test added to this PR.

You can find a reproducer in https://bugs.openjdk.org/browse/JDK-8277444 with instructions.

I don't think it is possible to create a reliable jtreg test. The data race depends on hardware very much.
You need delays selected in such a way the retransforming process is going behind the linking process in terms of rewritten bytecodes.

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

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

From dholmes at openjdk.org  Thu Aug 28 06:02:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 06:02:47 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v2]
In-Reply-To: <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>
Message-ID: <xvfT4UTH12qNL2XdpS1HpUxbesJu2HkxOq-btMgL8ao=.bfa7e1a7-09b7-4f24-b49b-f038812e2ae7@github.com>

On Thu, 21 Aug 2025 16:01:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates
>>   `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();`
>> to find if method exit normally or by exception.
>> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See
>> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)`
>> where post_method_exit_inner is called directly.
>> 
>> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. 
>> 
>> 
>> The fix was a part of
>> https://github.com/openjdk/jdk/pull/26713
>> for
>> https://bugs.openjdk.org/browse/JDK-8365192
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assertion added.

Looks good. A few style nits and a couple of suggestions.

This will make the other PR much easier to review.

Thanks

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

> 1841:   // return a flag when a method terminates by throwing an exception
> 1842:   // i.e. if an exception is thrown and it's not caught by the current method
> 1843:   bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();

Can we assert this is not an exception exit please.

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

> 1849:     BasicType type = current_frame.interpreter_frame_result(&oop_result, &value);
> 1850:     assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0,
> 1851:       "Stack shouldn't be empty");

Suggestion:

    assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0,
           "Stack shouldn't be empty");

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

> 1862:   // Deferred transition to VM, so we can stash away the return oop before GC
> 1863:   // Note that this transition is not needed when throwing an exception, because
> 1864:   // there is no oop to retain.

The comment on lines 1863-1864 is no longer needed.

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

> 1865:   JavaThread* current = thread; // for JRT_BLOCK
> 1866:   JRT_BLOCK
> 1867:     post_method_exit_inner(thread, mh, state, false, current_frame, value);

Suggestion:

    post_method_exit_inner(thread, mh, state, false /* not exception exit */, current_frame, value);

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/TestMethodExitWithPendingException.java line 27:

> 25:  * @test
> 26:  * @summary Test verifies that MethodExit event is correctly posted
> 27:  * if method is called while there is a pending exception on this thread.

Suggestion:

 * @summary Test verifies that MethodExit event is correctly posted
 *          if method is called while there is a pending exception on this thread.

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 33:

> 31: // This method exit callback actually works only for 2 methods:
> 32: // 1) for ExceptionExit it verifies that method exit
> 33: //    has been popped by exception and call 'upCall' mthod using JNI.

Suggestion:

//    has been popped by exception and calls 'upCall' method using JNI.

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 40:

> 38: cbMethodExit(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jmethodID method,
> 39:              jboolean was_popped_by_exception, jvalue return_value) {
> 40:   const char * mname = get_method_name(jvmti, jni, method);

Style nit: please bind the `*` to the type in all pointer declarations e.g. `char* mname` not `char * mname` or `char *mname`.  At present all three variants exist in the code. Thanks

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 67:

> 65:   }
> 66:   jmethodID upcall_method = jni->GetStaticMethodID(main_class,
> 67:       "upCall", "()Ljava/lang/String;");

Suggestion:

  jmethodID upcall_method = jni->GetStaticMethodID(main_class,
                                                   "upCall", "()Ljava/lang/String;");

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 104:

> 102:   check_jvmti_error(err, "SetEventCallbacks");
> 103:   jvmti_env = jvmti;
> 104:  return JNI_OK;

Suggestion:

  jvmti_env = jvmti;
  return JNI_OK;

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 109:

> 107: 
> 108: extern "C" {
> 109: JNIEXPORT void JNICALL

Suggestion:

extern "C" {

JNIEXPORT void JNICALL

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 125:

> 123: }
> 124: 
> 125: }

Suggestion:

} // extern "C"

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26886#pullrequestreview-3163239887
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306237793
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306236038
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306244212
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306236955
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306247384
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306249362
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306260149
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306252496
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306255064
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306256945
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306257329

From duke at openjdk.org  Thu Aug 28 09:12:53 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 28 Aug 2025 09:12:53 GMT
Subject: RFR: 8366331: Sort share/prims includes
Message-ID: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>

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

Passes `tier1`.

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

Commit messages:
 - sort and delete

Changes: https://git.openjdk.org/jdk/pull/26980/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26980&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366331
  Stats: 72 lines in 26 files changed: 31 ins; 39 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26980.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26980/head:pull/26980

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

From duke at openjdk.org  Thu Aug 28 09:35:24 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 28 Aug 2025 09:35:24 GMT
Subject: RFR: 8366331: Sort share/prims includes [v2]
In-Reply-To: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
Message-ID: <aYieVKMh_YPWU5AaqYhzLmRKk4zFA7TjTvrU4cCZqac=.fcec09ae-4729-42df-8b8e-04493586f58d@github.com>

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

Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8366331
 - sort and delete

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

Changes: https://git.openjdk.org/jdk/pull/26980/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26980&range=01
  Stats: 72 lines in 26 files changed: 31 ins; 39 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26980.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26980/head:pull/26980

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

From shade at openjdk.org  Thu Aug 28 09:38:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Aug 2025 09:38:43 GMT
Subject: RFR: 8366331: Sort share/prims includes [v2]
In-Reply-To: <aYieVKMh_YPWU5AaqYhzLmRKk4zFA7TjTvrU4cCZqac=.fcec09ae-4729-42df-8b8e-04493586f58d@github.com>
References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
 <aYieVKMh_YPWU5AaqYhzLmRKk4zFA7TjTvrU4cCZqac=.fcec09ae-4729-42df-8b8e-04493586f58d@github.com>
Message-ID: <pCe4l_cGhhr0QFC1rf4J_mWTv-N363QUBlQewEgtk64=.2284840d-3aad-4a4c-86e9-7dd210d3c36a@github.com>

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

>> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8366331
>  - sort and delete

Looks fine with minor nit.

src/hotspot/share/prims/foreignGlobals.cpp line 25:

> 23: 
> 24: #include "classfile/javaClasses.hpp"
> 25: #include "foreignGlobals.hpp"

This does not look right, even in the original code. Isn't it the same as `prims/foreignGlobals.hpp`, which is subsumed by the existing `prims/foreignGlobals.inline.hpp`?

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

PR Review: https://git.openjdk.org/jdk/pull/26980#pullrequestreview-3164054837
PR Review Comment: https://git.openjdk.org/jdk/pull/26980#discussion_r2306829785

From mbaesken at openjdk.org  Thu Aug 28 12:00:44 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Aug 2025 12:00:44 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v2]
In-Reply-To: <_dzoj_TlgAVspeaYaN5Vaflby5PlodGQ4n3gPXUWIVg=.6933935b-3db2-4430-a5a0-cc44f733dc2b@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
 <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>
 <_dzoj_TlgAVspeaYaN5Vaflby5PlodGQ4n3gPXUWIVg=.6933935b-3db2-4430-a5a0-cc44f733dc2b@github.com>
Message-ID: <U4PBYZk4xiJVr97NKumH2Ablv1mxEJs32zrc0bjm2qU=.d706ee8d-3ec1-434e-a334-3703b9432a68@github.com>

On Wed, 27 Aug 2025 17:44:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> so does that other code have the same analyzer warning?

The other one from os_perf_linux.cpp  is Hotspot/C++ code and the gcc static analyzer does not work well with C++ (see https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110 ).  In the future it  will most likely support C++ too.

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

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

From mbaesken at openjdk.org  Thu Aug 28 12:00:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Aug 2025 12:00:46 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v2]
In-Reply-To: <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
 <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>
Message-ID: <f7jd1xPSJsOEav1MF6fVGmaCiSFyzJmw2tBdR2tq4OE=.ea5dec14-c763-4261-9ef6-07a847db467b@github.com>

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

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

I think initializing the vars is a good practise.  And checking for `!= 2`  as you suggested makes sense and should be done here (as we do  in Hotspot).

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

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

From duke at openjdk.org  Thu Aug 28 13:01:37 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 28 Aug 2025 13:01:37 GMT
Subject: RFR: 8366331: Sort share/prims includes [v3]
In-Reply-To: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
Message-ID: <lqADm7wLPFgpMmeDjD5G7mAqM9QdkpkfowDiSSzjEZo=.23e4374d-10bc-4a12-b145-35e964f13fa9@github.com>

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

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

  nn

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26980/files
  - new: https://git.openjdk.org/jdk/pull/26980/files/d80d6764..b0d16339

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

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

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

From duke at openjdk.org  Thu Aug 28 13:01:39 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 28 Aug 2025 13:01:39 GMT
Subject: RFR: 8366331: Sort share/prims includes [v3]
In-Reply-To: <pCe4l_cGhhr0QFC1rf4J_mWTv-N363QUBlQewEgtk64=.2284840d-3aad-4a4c-86e9-7dd210d3c36a@github.com>
References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
 <aYieVKMh_YPWU5AaqYhzLmRKk4zFA7TjTvrU4cCZqac=.fcec09ae-4729-42df-8b8e-04493586f58d@github.com>
 <pCe4l_cGhhr0QFC1rf4J_mWTv-N363QUBlQewEgtk64=.2284840d-3aad-4a4c-86e9-7dd210d3c36a@github.com>
Message-ID: <Dtm88qZltwW8RnZDtxYm6M7yv_7i6niy-lmpTKKzTlY=.c22f40d5-fafb-4f27-a38e-bd59ea8e78a9@github.com>

On Thu, 28 Aug 2025 09:31:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   nn
>
> src/hotspot/share/prims/foreignGlobals.cpp line 25:
> 
>> 23: 
>> 24: #include "classfile/javaClasses.hpp"
>> 25: #include "foreignGlobals.hpp"
> 
> This does not look right, even in the original code. Isn't it the same as `prims/foreignGlobals.hpp`, which is subsumed by the existing `prims/foreignGlobals.inline.hpp`?

Right, removed in b0d163391270189772939ef2849e45dbf5963063

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26980#discussion_r2307338536

From lkorinth at openjdk.org  Thu Aug 28 13:05:51 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:05:51 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <EJdxiot32oUpUVtRSTMTXFSFI9pOkmb17vwLGEKmuK0=.a14f9df8-b05a-4a59-a5c0-039070d059ff@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> > @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.
> 
> I don't agree. If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.
> 
> I am also questioning whether such a time out was demonstrated for this test. I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test. I can send you my query off-line so you can check it. Maybe it is incomplete.

I will revert this change. Thanks for finding it. I think the timeout was found in a local run with a timeout factor of 0.5 and a local fix to "CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE". CI history tells me that the run time of the test is stable and that we have a margin.

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

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

From lkorinth at openjdk.org  Thu Aug 28 13:12:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:12:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v6]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <mygrl66-jtLOCitZE1y7w005QUUFmtZ0QDWPO5FD8pQ=.9558b892-2b3a-4c1e-b898-51b86d61beb0@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 two additional commits since the last revision:

 - revert added timeout, it is not needed
 - feedback from Mark Sheppard

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/f24a1e72..365454d2

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

  Stats: 62 lines in 41 files changed: 3 ins; 0 del; 59 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  Thu Aug 28 13:12:46 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:12:46 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <O2hQ5ow7drkJOD-QiVkoDFa9ChZmv3WEOTqLgH3r8lQ=.b12f1c30-cfe8-4797-a964-67429193f9d9@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

I have added some updates. I will try to merge latest, update copyrights and run tests over the weekend.

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

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

From shade at openjdk.org  Thu Aug 28 14:50:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Aug 2025 14:50:44 GMT
Subject: RFR: 8366331: Sort share/prims includes [v3]
In-Reply-To: <lqADm7wLPFgpMmeDjD5G7mAqM9QdkpkfowDiSSzjEZo=.23e4374d-10bc-4a12-b145-35e964f13fa9@github.com>
References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
 <lqADm7wLPFgpMmeDjD5G7mAqM9QdkpkfowDiSSzjEZo=.23e4374d-10bc-4a12-b145-35e964f13fa9@github.com>
Message-ID: <kll-HJOJcyeGwMM9KkxxVYVrLYHpMtkYmW7KUAnGblA=.b5a2380c-58d9-4240-aab9-8b1a13e7576c@github.com>

On Thu, 28 Aug 2025 13:01:37 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nn

This looks fine to me, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26980#pullrequestreview-3165215879

From lmesnik at openjdk.org  Thu Aug 28 16:41:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 28 Aug 2025 16:41:56 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v3]
In-Reply-To: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
Message-ID: <566ef980l4Ql3HYnexGwX9JKkpaY8tOtlHqt2Vi-7t4=.856dddd4-93f3-4d80-9b3c-d3a8d795dc4e@github.com>

> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates
>   `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();`
> to find if method exit normally or by exception.
> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See
> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)`
> where post_method_exit_inner is called directly.
> 
> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. 
> 
> 
> The fix was a part of
> https://github.com/openjdk/jdk/pull/26713
> for
> https://bugs.openjdk.org/browse/JDK-8365192

Leonid Mesnik has updated the pull request 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 27 additional commits since the last revision:

 - Apply suggestions from code review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - comment fixed
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8365937
 - assertion added.
 - more comments in the test
 - fixed ident
 - bugid fixed:
 - updated to fix 8365937
 - fixed comment.
 - test renamed.
 - ... and 17 more: https://git.openjdk.org/jdk/compare/dad9fd8a...4e05639a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26886/files
  - new: https://git.openjdk.org/jdk/pull/26886/files/d9319d90..4e05639a

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

  Stats: 6761 lines in 321 files changed: 3177 ins; 2467 del; 1117 mod
  Patch: https://git.openjdk.org/jdk/pull/26886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26886/head:pull/26886

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

From lmesnik at openjdk.org  Thu Aug 28 16:41:57 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 28 Aug 2025 16:41:57 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v3]
In-Reply-To: <xvfT4UTH12qNL2XdpS1HpUxbesJu2HkxOq-btMgL8ao=.bfa7e1a7-09b7-4f24-b49b-f038812e2ae7@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>
 <xvfT4UTH12qNL2XdpS1HpUxbesJu2HkxOq-btMgL8ao=.bfa7e1a7-09b7-4f24-b49b-f038812e2ae7@github.com>
Message-ID: <aOC-wve-ARp11g2AId1AFZMlybtobEFl-s0s1MuPtP8=.6850a2c1-e870-4acb-8c18-2f28514e9cbb@github.com>

On Thu, 28 Aug 2025 05:41:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision:
>> 
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - comment fixed
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365937
>>  - assertion added.
>>  - more comments in the test
>>  - fixed ident
>>  - bugid fixed:
>>  - updated to fix 8365937
>>  - fixed comment.
>>  - test renamed.
>>  - ... and 17 more: https://git.openjdk.org/jdk/compare/dad9fd8a...4e05639a
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1843:
> 
>> 1841:   // return a flag when a method terminates by throwing an exception
>> 1842:   // i.e. if an exception is thrown and it's not caught by the current method
>> 1843:   bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();
> 
> Can we assert this is not an exception exit please.

I am not sure what to check here. 
The 'exception_exit' can be true here. It means that it has been thrown in this thread and not caught yet. But this method is called after exception thrown.

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

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

From lmesnik at openjdk.org  Thu Aug 28 18:35:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 28 Aug 2025 18:35:43 GMT
Subject: RFR: 8366331: Sort share/prims includes [v3]
In-Reply-To: <lqADm7wLPFgpMmeDjD5G7mAqM9QdkpkfowDiSSzjEZo=.23e4374d-10bc-4a12-b145-35e964f13fa9@github.com>
References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
 <lqADm7wLPFgpMmeDjD5G7mAqM9QdkpkfowDiSSzjEZo=.23e4374d-10bc-4a12-b145-35e964f13fa9@github.com>
Message-ID: <PjBsgmGoOLXPv0V0wg-dfK0qP7aZzI67JDiWWvwJfPw=.4fdcc05f-5a39-4691-8de3-c516635d8716@github.com>

On Thu, 28 Aug 2025 13:01:37 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nn

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26980#pullrequestreview-3166072469

From duke at openjdk.org  Thu Aug 28 19:08:45 2025
From: duke at openjdk.org (duke)
Date: Thu, 28 Aug 2025 19:08:45 GMT
Subject: RFR: 8366331: Sort share/prims includes [v3]
In-Reply-To: <lqADm7wLPFgpMmeDjD5G7mAqM9QdkpkfowDiSSzjEZo=.23e4374d-10bc-4a12-b145-35e964f13fa9@github.com>
References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com>
 <lqADm7wLPFgpMmeDjD5G7mAqM9QdkpkfowDiSSzjEZo=.23e4374d-10bc-4a12-b145-35e964f13fa9@github.com>
Message-ID: <Bic_Tar5u5uZcLinFTGpGPG7k94DL05slAoglkjSLs4=.542b7972-4105-40b4-86e0-6336307bca97@github.com>

On Thu, 28 Aug 2025 13:01:37 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nn

@fandreuz 
Your change (at version b0d163391270189772939ef2849e45dbf5963063) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26980#issuecomment-3234629431

From eastigeevich at openjdk.org  Thu Aug 28 22:09:45 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 28 Aug 2025 22:09:45 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com>
Message-ID: <-rvuOLCVGMSDH-z_T310KDk6R39Qw0xSZlXDwd-6R6k=.55328043-0e2e-47d4-85d1-b08e21c9314d@github.com>

On Wed, 27 Aug 2025 20:05:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Symplify comments; Get JavaThread::current in variable
>
> You could separate the two if you'd like. I'm running tier1-4 testing on the PR I sent right now. Also, I haven't tried it on your test.
> Edit again: I don't see your test added to this PR.

@coleenp,

I managed to write a jtreg test.
Unfortunately it fails intermittently.

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

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

From dholmes at openjdk.org  Fri Aug 29 06:05:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 29 Aug 2025 06:05:48 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v3]
In-Reply-To: <aOC-wve-ARp11g2AId1AFZMlybtobEFl-s0s1MuPtP8=.6850a2c1-e870-4acb-8c18-2f28514e9cbb@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>
 <xvfT4UTH12qNL2XdpS1HpUxbesJu2HkxOq-btMgL8ao=.bfa7e1a7-09b7-4f24-b49b-f038812e2ae7@github.com>
 <aOC-wve-ARp11g2AId1AFZMlybtobEFl-s0s1MuPtP8=.6850a2c1-e870-4acb-8c18-2f28514e9cbb@github.com>
Message-ID: <ej_YqB2uft5_dHdSAt8VTxBQoSpW9MXtfj1lZ9pb0MI=.171572f8-c4e6-42c9-99b4-e8340d83b33c@github.com>

On Thu, 28 Aug 2025 16:30:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiExport.cpp line 1843:
>> 
>>> 1841:   // return a flag when a method terminates by throwing an exception
>>> 1842:   // i.e. if an exception is thrown and it's not caught by the current method
>>> 1843:   bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();
>> 
>> Can we assert this is not an exception exit please.
>
> I am not sure what to check here. 
> The 'exception_exit' can be true here. It means that it has been thrown in this thread and not caught yet. But this method is called after exception thrown.

But we are only in this method because the Java method has completed normally so there cannot be a pending exception at this point. ???

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

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

From lmesnik at openjdk.org  Fri Aug 29 06:56:45 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 29 Aug 2025 06:56:45 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v3]
In-Reply-To: <ej_YqB2uft5_dHdSAt8VTxBQoSpW9MXtfj1lZ9pb0MI=.171572f8-c4e6-42c9-99b4-e8340d83b33c@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <MrlJD5DPVShdK1V8RWgDfeacwoVcFbGv9wP9o23l65U=.f2f3efba-ab3d-4dfa-a652-e5690bc70263@github.com>
 <xvfT4UTH12qNL2XdpS1HpUxbesJu2HkxOq-btMgL8ao=.bfa7e1a7-09b7-4f24-b49b-f038812e2ae7@github.com>
 <aOC-wve-ARp11g2AId1AFZMlybtobEFl-s0s1MuPtP8=.6850a2c1-e870-4acb-8c18-2f28514e9cbb@github.com>
 <ej_YqB2uft5_dHdSAt8VTxBQoSpW9MXtfj1lZ9pb0MI=.171572f8-c4e6-42c9-99b4-e8340d83b33c@github.com>
Message-ID: <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com>

On Fri, 29 Aug 2025 06:03:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I am not sure what to check here. 
>> The 'exception_exit' can be true here. It means that it has been thrown in this thread and not caught yet. But this method is called after exception thrown.
>
> But we are only in this method because the Java method has completed normally so there cannot be a pending exception at this point. ???

There is might be exception if current method has been called after exception has been thrown. It is quite rare case, but I've seem when add `assert(!exception_exit, "")`. It might happens if exception thrown  and there were other upcals  in the same thread before exception has been caught. I think I've seen it during classloading or some method bootstrapping.

The test `TestMethodExitWithPendingException`  simulates the same issue by calling method in the MethodExit event call back.
For method `upCall` the `exception_exit` would be true, because the method is called while exception is pending. However, the method `upCall` exits normally and is not unwinded. So this method `post_method_exit` is called.

Here is the example of such stack in the on of the tests were assertion has been hit. The VM tries to load classes when exception is throwing.

V  [libjvm.so+0x1415d6c]  JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x29c  (jvmtiExport.cpp:1847)
V  [libjvm.so+0x1066b86]  InterpreterRuntime::post_method_exit(JavaThread*)+0xe6  (interpreterRuntime.cpp:1278)
j  java.lang.Object.<init>()V+0 java.base at 26-internal
j  java.lang.Throwable.<init>(Ljava/lang/String;)V+1 java.base at 26-internal
j  java.lang.Error.<init>(Ljava/lang/String;)V+2 java.base at 26-internal
j  java.lang.LinkageError.<init>(Ljava/lang/String;)V+2 java.base at 26-internal
j  java.lang.NoClassDefFoundError.<init>(Ljava/lang/String;)V+2 java.base at 26-internal
v  ~StubRoutines::Stub Generator call_stub_stub 0x00007f81b7c876fd
V  [libjvm.so+0x1089117]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4f7  (javaCalls.cpp:415)
V  [libjvm.so+0x108ab3f]  JavaCalls::call_special(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x18f  (javaCalls.cpp:323)
V  [libjvm.so+0x108b3c6]  JavaCalls::construct_new_instance(InstanceKlass*, Symbol*, JavaCallArguments*, JavaThread*)+0x116  (javaCalls.cpp:289)
V  [libjvm.so+0xd74f4b]  Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle)+0x1db  (exceptions.cpp:320)
V  [libjvm.so+0xd7517f]  Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle, Handle)+0x2f  (exceptions.cpp:341)
V  [libjvm.so+0xd7609f]  Exceptions::new_exception(JavaThread*, Symbol*, char const*, Handle, Handle, Exceptions::ExceptionMsgToUtf8Mode)+0x3bf  (exceptions.cpp:424)
V  [libjvm.so+0xd7b9a0]  Exceptions::_throw_msg_cause(JavaThread*, char const*, int, Symbol*, char const*, Handle)+0x60  (exceptions.cpp:208)
V  [libjvm.so+0x1ad397b]  handle_resolution_exception(Symbol*, bool, JavaThread*)+0x22b  (systemDictionary.cpp:313)
V  [libjvm.so+0x1adef82]  SystemDictionary::resolve_with_circularity_detection(Symbol*, Symbol*, Handle, bool, JavaThread*)+0x282  (systemDictionary.cpp:487)
V  [libjvm.so+0xa9baf2]  ClassFileParser::post_process_parsed_stream(ClassFileStream const*, ConstantPool*, JavaThread*)+0x402  (systemDictionary.hpp:118)
V  [libjvm.so+0xaa3142]  ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*)+0x192  (classFileParser.cpp:5425)
V  [libjvm.so+0x146d4f5]  KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*)+0x195  (klassFactory.cpp:202)
V  [libjvm.so+0x1add90c]  SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*)+0xfc  (systemDictionary.cpp:869)
V  [libjvm.so+0x1262042]  jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*)+0x322  (jvm.cpp:886)
V  [libjvm.so+0x12622f5]  JVM_DefineClassWithSource+0xa5  (jvm.cpp:1053)
C  [libjava.so+0xe659]  Java_java_lang_ClassLoader_defineClass1+0x1a9  (ClassLoader.c:139)
j  java.lang.ClassLoader.defineClass1(Ljava/lang/ClassLoader;Ljava/lang/String;[BIILjava/security/ProtectionDomain;Ljava/lang/String;)Ljava/lang/Class;+0 java.base at 26-internal
j  java.lang.ClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/ProtectionDomain;)Ljava/lang/Class;+27 java.base at 26-internal
j  java.security.SecureClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/CodeSource;)Ljava/lang/Class;+12 java.base at 26-internal
j  java.net.URLClassLoader.defineClass(Ljava/lang/String;Ljdk/internal/loader/Resource;)Ljava/lang/Class;+220 java.base at 26-internal
j  java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+30 java.base at 26-internal
j  java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+69 java.base at 26-internal
j  java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 java.base at 26-internal
v  ~StubRoutines::Stub Generator call_stub_stub 0x00007f81b7c876fd
V  [libjvm.so+0x1089117]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4f7  (javaCalls.cpp:415)
V  [libjvm.so+0x1089873]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x313  (javaCalls.cpp:323)
V  [libjvm.so+0x1089fba]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, JavaThread*)+0xca  (javaCalls.cpp:192)
V  [libjvm.so+0x1adfa90]  SystemDictionary::load_instance_class_impl(Symbol*, Handle, JavaThread*)+0x1e0  (systemDictionary.cpp:1269)
V  [libjvm.so+0x1addb3c]  SystemDictionary::load_instance_class(Symbol*, Handle, JavaThread*)+0x1c  (systemDictionary.cpp:1300)
V  [libjvm.so+0x1ade768]  SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, JavaThread*)+0xa48  (systemDictionary.cpp:694)
V  [libjvm.so+0x1adec82]  SystemDictionary::resolve_or_fail(Symbol*, Handle, bool, JavaThread*)+0x22  (systemDictionary.cpp:332)
V  [libjvm.so+0xb9d6a5]  ConstantPool::klass_at_impl(constantPoolHandle const&, int, JavaThread*)+0x185  (constantPool.cpp:665)
V  [libjvm.so+0x106df52]  InterpreterRuntime::_new(JavaThread*, ConstantPool*, int)+0xb2  (constantPool.hpp:423)
j  TestClassResolutionFail.test1()V+0

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

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

From sroy at openjdk.org  Fri Aug 29 08:50:37 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 29 Aug 2025 08:50:37 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v5]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <D2iufQhiyPLZCotKssNteiNXs_X1wzP4MlL3DZLy0N8=.5e310421-11e7-4db2-ad7d-580044c2402c@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 two additional commits since the last revision:

 - Thread safety,struct and perfInit()
 - Thread safety,struct and perfInit()

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

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

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

  Stats: 121 lines in 1 file changed: 62 ins; 40 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332

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

From sroy at openjdk.org  Fri Aug 29 08:56:56 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 29 Aug 2025 08:56:56 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v6]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <sNkjTIdB4hhRCT7pzNZc6-5YYPbujw4UPPS5BOnKIyQ=.53da5534-6479-4dc7-9997-3ed38f097fd8@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 12 commits:

 - Merge branch 'openjdk:master' into cpuprocessload
 - Thread safety,struct and perfInit()
 - Thread safety,struct and perfInit()
 - Update ProblemList.txt
 - Merge branch 'master' into cpuprocessload
 - Merge branch 'master' into cpuprocessload
 - Update UnixOperatingSystem.c
 - Merge branch 'openjdk:master' into cpuprocessload
 - cleanup
 - system cpu load
 - ... and 2 more: https://git.openjdk.org/jdk/compare/86d6a2e0...46dcf313

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

Changes: https://git.openjdk.org/jdk/pull/25332/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=05
  Stats: 100 lines in 2 files changed: 94 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  Fri Aug 29 10:22:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 29 Aug 2025 10:22:48 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v2]
In-Reply-To: <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
 <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>
Message-ID: <Y8RlAnI4cnoVsUFLxIF-zheY9imYZ0ByobcJmPh-W3I=.3ab4f221-04c1-43f8-a654-4ccb3edb6325@github.com>

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

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

Assigning zero to values we are about to set with vsscanf, or are going to ignore, is being added here to keep the analyzer happy.    I think we should not do this, and leave the initialization to scanf.  (Unless there is some case where it creates a problem.)

The extra initialization looks harmless, and while not hugely wasteful, if we do this one, then it starts a long path of adding extra initialization as we have various other examples.

"src/hotspot/os/linux/os_perf_linux.cpp" as discussed has the same.

Back in 
"src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c"

get_totalticks:

 87 static int get_totalticks(int which, ticks *pticks) {
...
 89     uint64_t        userTicks, niceTicks, systemTicks, idleTicks;
 90     uint64_t        iowTicks = 0, irqTicks = 0, sirqTicks= 0;
...
 97     n = fscanf(fh, "cpu " DEC_64 " " DEC_64 " " DEC_64 " " DEC_64 " " DEC_64 " "
 98                    DEC_64 " " DEC_64,
 99            &userTicks, &niceTicks, &systemTicks, &idleTicks,
100            &iowTicks, &irqTicks, &sirqTicks);


This one does not initialize userTicks and 3 others, but does initialize iowTicks and others.
We check fscanf result < 4 to mean an error, it failed to read the essential values (that we don't manually initialize).

Other examples include src/java.base/unix/native/jspawnhelper/jspawnhelper.c
where local int variables are initialized only by a call to scanf, or otherwise ignored.

(There are examples where we do initialize such a local int, but that doesn't mean it's necessary.)

I'd recommend we don't start initializing things that we can see are either initialized slightly later, or are ignored.

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

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

From kevinw at openjdk.org  Fri Aug 29 12:18:43 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 29 Aug 2025 12:18:43 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: <EQ4DDqS81Obi9N64Dzg51KZfoWuQy99jqOmA-yKCZNI=.01652c6a-4214-4e8a-a638-866da47a92a3@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

Pending CSR.

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

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

From coleenp at openjdk.org  Fri Aug 29 12:58:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 29 Aug 2025 12:58:45 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <F5wBMFVi24FTOoSB4vcbDoWTlsw2NeZo7ZDITNRE_vA=.5db8a8e8-d251-40af-8287-51092f871503@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com>
 <F5wBMFVi24FTOoSB4vcbDoWTlsw2NeZo7ZDITNRE_vA=.5db8a8e8-d251-40af-8287-51092f871503@github.com>
Message-ID: <-DYS7TMcvWFWplKvbjU4l2rrgc-qu2WyKNV0vn08yTs=.c35f5ae6-25f7-47b8-8275-26eaf23c43e0@github.com>

On Wed, 27 Aug 2025 06:37:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> (I realize this is a tangent, but maybe there is a separate bug here...)
>> 
>>> To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror).
>> 
>> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced:
>> 
>> https://github.com/openjdk/jdk/blob/c75534517729b903b63263cf64dc2ff841e3dcb1/src/hotspot/share/oops/instanceKlass.cpp#L1064
>> 
>> Class.forName(name, false, loader) would result in a prepared class but without the event being sent.
>
>> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced
> 
> @dean-long it seems the JVM TI "prepare" event is somewhat misnamed. It states "At this point, class fields, methods, and implemented interfaces are available, and no code from the class has been executed." but that neither describes preparation, nor the rest of linking. You can only access fields and methods after a class has been initialized! But lets take this elsewhere if needed.

Does it fail with the patch?  Sorry for the delay.  @dholmes-ora and I have been discussing how all this works offline, but with time-zone differences, we won't have any agreement until next week.  I wrote a more limited version of the patch I sent and am testing it now.

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

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

From mbaesken at openjdk.org  Fri Aug 29 14:11:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 29 Aug 2025 14:11:01 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v2]
In-Reply-To: <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
 <x9qr_uTQsBylJzSEnZUdU1HcNxEPiejXxjIUs_4bSQE=.4c3c2282-02ee-45f9-918a-e12d9f4865c2@github.com>
Message-ID: <OFtJW-g51j8I4naZIL4_769ZSe8oSTggra9EmbiXa-A=.087f6c87-1c4d-4aea-a843-42baa4588e5f@github.com>

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

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

Okay then let's avoid the initialization.

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

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

From coleenp at openjdk.org  Fri Aug 29 14:10:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 29 Aug 2025 14:10:47 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <PVE_PoKY90_kEvwlfA5kpPXcRXwYmJijSHP-j9cERzk=.ba70ad9f-7838-4ba2-927d-bd79605b49bf@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

Okay I ran the test case in the issue and I see why it wouldn't be reliable.  I verified it with the new more minimalistic patch here: https://github.com/openjdk/jdk/pull/26971

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

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

From mbaesken at openjdk.org  Fri Aug 29 14:11:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 29 Aug 2025 14:11:01 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v3]
In-Reply-To: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
Message-ID: <mFCocD24ZlodX8iS45JnH_8H2-RLYBTPOFTu-OyCTYU=.c7641333-d14c-44f8-bb68-4c796c619dc8@github.com>

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

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

  Avoid initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26962/files
  - new: https://git.openjdk.org/jdk/pull/26962/files/cb0f8dfc..daf31fe6

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

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

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

From kevinw at openjdk.org  Fri Aug 29 14:13:42 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 29 Aug 2025 14:13:42 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v3]
In-Reply-To: <mFCocD24ZlodX8iS45JnH_8H2-RLYBTPOFTu-OyCTYU=.c7641333-d14c-44f8-bb68-4c796c619dc8@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
 <mFCocD24ZlodX8iS45JnH_8H2-RLYBTPOFTu-OyCTYU=.c7641333-d14c-44f8-bb68-4c796c619dc8@github.com>
Message-ID: <ov9FS16cbr4_EmOcZR5CFSfkXizE3KejIyVx6-a2Jjk=.3a6f7475-59b0-4510-9633-5e11ac8540a5@github.com>

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

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

Marked as reviewed by kevinw (Reviewer).

Thanks!

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

PR Review: https://git.openjdk.org/jdk/pull/26962#pullrequestreview-3168897601
PR Comment: https://git.openjdk.org/jdk/pull/26962#issuecomment-3237175399

From asteiner at openjdk.org  Fri Aug 29 14:26:13 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Fri, 29 Aug 2025 14:26:13 GMT
Subject: RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning:
 use of uninitialized value 'systemTicks' [v3]
In-Reply-To: <mFCocD24ZlodX8iS45JnH_8H2-RLYBTPOFTu-OyCTYU=.c7641333-d14c-44f8-bb68-4c796c619dc8@github.com>
References: <Xtuc-XzN9PrfsXTINWSk6WV05ytWN9hz0C7wIFlXNy8=.a00fc7b4-8579-4c26-9198-8c770989fdf9@github.com>
 <mFCocD24ZlodX8iS45JnH_8H2-RLYBTPOFTu-OyCTYU=.c7641333-d14c-44f8-bb68-4c796c619dc8@github.com>
Message-ID: <l4lKnF-II5J5qPXgcArQAj9T4ijAlL0LLa6nybEKeWI=.b3302d1c-7b40-429c-bcaf-27c4caa2676c@github.com>

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

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

Marked as reviewed by asteiner (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/26962#pullrequestreview-3168939581

From lkorinth at openjdk.org  Fri Aug 29 14:41:48 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 29 Aug 2025 14:41:48 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v6]
In-Reply-To: <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>
Message-ID: <U44eId1pfiGjDkIlPM5vo-4Y_Oq-QdjIdCTFbD5O94E=.0f31a90c-9106-4cf5-a50f-4e7551eb14ff@github.com>

On Tue, 26 Aug 2025 17:06:08 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert added timeout, it is not needed
>>  - feedback from Mark Sheppard
>
> test/jdk/sun/security/krb5/name/Constructors.java line 28:
> 
>> 26:  * @summary Make PrincipalName and Realm immutable
>> 27:  * @modules java.security.jgss/sun.security.krb5
>> 28:  * @run main/othervm Constructors
> 
> Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second.

I have not analysed why. I can see 1013 occurrences in our test history where the test takes 2 minutes or more. On different CPU platforms.

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

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

From eastigeevich at openjdk.org  Fri Aug 29 15:34:44 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 29 Aug 2025 15:34:44 GMT
Subject: RFR: 8277444: Race condition on
 Instrumentation.retransformClasses() and class linking [v3]
In-Reply-To: <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
Message-ID: <C6dhH8TranJoFcHrllc_Hfd7TquAHUIzEYolvFys9Kw=.68284648-f5e2-4880-9335-7fc0ec2449e3@github.com>

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

> Okay I ran the test case in the issue and I see why it wouldn't be reliable. I verified it with the new more minimalistic patch here: #26971

Thank you for the minimalistic patch.

I now have a version of the jtreg test which fails more reliably. 
The test always passes the the previous version of #26971.

BTW I have updated the title of [JDK-8277444](https://bugs.openjdk.org/browse/JDK-8277444).
The issue is the data race between copy_bytecodes and class linking. So we must guarantee no data race when copy_bytecodes is used.

I'll add the test to the PR soon.

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

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

From pchilanomate at openjdk.org  Fri Aug 29 18:45:05 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 29 Aug 2025 18:45:05 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v3]
In-Reply-To: <566ef980l4Ql3HYnexGwX9JKkpaY8tOtlHqt2Vi-7t4=.856dddd4-93f3-4d80-9b3c-d3a8d795dc4e@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
 <566ef980l4Ql3HYnexGwX9JKkpaY8tOtlHqt2Vi-7t4=.856dddd4-93f3-4d80-9b3c-d3a8d795dc4e@github.com>
Message-ID: <zgZo8E_d1a-pY2pjSoRrDVquq62r4LHmt8hywBP5sVk=.b3b39ba5-7538-4e47-9934-ffb000e186e9@github.com>

On Thu, 28 Aug 2025 16:41:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates
>>   `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();`
>> to find if method exit normally or by exception.
>> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See
>> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)`
>> where post_method_exit_inner is called directly.
>> 
>> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. 
>> 
>> 
>> The fix was a part of
>> https://github.com/openjdk/jdk/pull/26713
>> for
>> https://bugs.openjdk.org/browse/JDK-8365192
>
> Leonid Mesnik has updated the pull request 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 27 additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - comment fixed
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8365937
>  - assertion added.
>  - more comments in the test
>  - fixed ident
>  - bugid fixed:
>  - updated to fix 8365937
>  - fixed comment.
>  - test renamed.
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/01e62e37...4e05639a

LGTM. Thanks for fixing and adding the extra tests.

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 48:

> 46:     const char *str = jni->GetStringUTFChars(upcall_result, nullptr);
> 47:     if (str == nullptr) {
> 48:       fatal(jni ,"Failed to convert Java string to C string.");

Suggestion:

      fatal(jni, "Failed to convert Java string to C string.");

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 63:

> 61:   jclass main_class = jni->FindClass("TestMethodExitWithPendingException");
> 62:   if (main_class == nullptr) {
> 63:     fatal(jni,"Can't find TestMethodExitWithPendingException class.");

Suggestion:

    fatal(jni, "Can't find TestMethodExitWithPendingException class.");

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 69:

> 67:                                                    "upCall", "()Ljava/lang/String;");
> 68:   if (upcall_method == nullptr) {
> 69:     fatal(jni,"Can't find upCall method.");

Suggestion:

    fatal(jni, "Can't find upCall method.");

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 76:

> 74:   const char *str = jni->GetStringUTFChars(upcall_result, nullptr);
> 75:   if (str == nullptr) {
> 76:     fatal(jni ,"Failed to convert Java string to C string.");

Suggestion:

    fatal(jni, "Failed to convert Java string to C string.");

test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PoppedByException/libTestPoppedByException.cpp line 39:

> 37:     }
> 38:     if (return_value.l != nullptr) {
> 39:       fatal(jni ,"return_value should be nullptr.");

Suggestion:

      fatal(jni, "return_value should be nullptr.");

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26886#pullrequestreview-3169698189
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310845150
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310846119
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310846950
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310847641
PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310849997

From lkorinth at openjdk.org  Fri Aug 29 18:45:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 29 Aug 2025 18:45:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v7]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <2IfOGWu0Kfw8qdRmYLkMEdF5kvlC5lcuc-USAovOTFM=.f6d2a6c9-160d-478e-aa5c-1086b40e52bd@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:

  update copyright

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

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

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

  Stats: 233 lines in 233 files changed: 0 ins; 0 del; 233 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 lmesnik at openjdk.org  Fri Aug 29 19:11:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 29 Aug 2025 19:11:04 GMT
Subject: RFR: 8365937: post_method_exit might incorrectly set
 was_popped_by_exception and value in the middle of stack unwinding [v4]
In-Reply-To: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
References: <VsZdDh6LK1SRnCxK0jlgV_K6lqp2wfIe0d05QuBkui0=.40b0221c-0f7a-4a0f-b36a-9f93e972f44c@github.com>
Message-ID: <xT5AoTfA0VvTmGZqTuVoZtrBJf4NifwAXF1hR_Jbh5w=.ecffaf10-4c52-4d76-ac34-13a21b2567d1@github.com>

> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates
>   `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();`
> to find if method exit normally or by exception.
> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See
> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)`
> where post_method_exit_inner is called directly.
> 
> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. 
> 
> 
> The fix was a part of
> https://github.com/openjdk/jdk/pull/26713
> for
> https://bugs.openjdk.org/browse/JDK-8365192

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

 - Apply suggestions from code review
   
   Co-authored-by: Patricio Chilano Mateo <patricio.chilano.mateo at oracle.com>
 - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp
   
   Co-authored-by: Patricio Chilano Mateo <patricio.chilano.mateo at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26886/files
  - new: https://git.openjdk.org/jdk/pull/26886/files/4e05639a..09607978

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

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

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

From eastigeevich at openjdk.org  Fri Aug 29 22:48:06 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 29 Aug 2025 22:48:06 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v4]
In-Reply-To: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
Message-ID: <ycjD7BT8p5lmyM44Tee59ugwvauK0t0E9z6bnzMsn88=.17ffe200-266e-4fbe-b726-86f96673d7c0@github.com>

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

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

 - Merge branch 'master' into JDK-8277444
 - Link classes before copy_bytecodes; Add regression test
 - Symplify comments; Get JavaThread::current in variable
 - Add missing include runtime/synchronizer.hpp
 - 8277444: Race condition on Instrumentation.retransformClasses() and class linking

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

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

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

  Stats: 21687 lines in 641 files changed: 14684 ins; 4507 del; 2496 mod
  Patch: https://git.openjdk.org/jdk/pull/26863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26863/head:pull/26863

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

From eastigeevich at openjdk.org  Fri Aug 29 22:58:43 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 29 Aug 2025 22:58:43 GMT
Subject: RFR: 8277444: Data race between
 JvmtiClassFileReconstituter::copy_bytecodes and class linking [v3]
In-Reply-To: <PVE_PoKY90_kEvwlfA5kpPXcRXwYmJijSHP-j9cERzk=.ba70ad9f-7838-4ba2-927d-bd79605b49bf@github.com>
References: <PiD70RIheOTp2Md4McCbOQGy6PB6U242s-T2ovUUqjg=.397cd634-8ca1-478a-b2d3-71123b55ca89@github.com>
 <GMMfnjsN6csR0f7w_CgYuetJZi5ctgStPi8yS261cd4=.97608a41-afd2-4a58-883c-602eaf8e8687@github.com>
 <PVE_PoKY90_kEvwlfA5kpPXcRXwYmJijSHP-j9cERzk=.ba70ad9f-7838-4ba2-927d-bd79605b49bf@github.com>
Message-ID: <NpkGo5jakcuo6PsvXnXGDP7WfkxRVJoJ__ABZRy4QQA=.ceea0117-fa4f-431c-b622-78bd43bc16eb@github.com>

On Fri, 29 Aug 2025 14:07:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Symplify comments; Get JavaThread::current in variable
>
> Okay I ran the test case in the issue and I see why it wouldn't be reliable.  I verified it with the new more minimalistic patch here: https://github.com/openjdk/jdk/pull/26971

@coleenp,

I have pulled your changes.
I added a `guarantee` check to `copy_bytecodes`. IMO it's better to be overcautious to prevent incorrect uses of `copy_bytes`.  Because of it I had to add `link_class` to `GetBytecodes`.

I don't use the macros because they rely on `THREAD`.  It is a variable in your patch but it is usually used as a macro.

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

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

From iklam at openjdk.org  Sat Aug 30 02:18:24 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 30 Aug 2025 02:18:24 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache()
Message-ID: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>

Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
- tests if an object is inside the AOT cache's metaspace region.

Also various forms of  "shared metaspace" are updated to "aot metaspace"

Please start your review with allocations.hpp

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

Commit messages:
 - 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache()

Changes: https://git.openjdk.org/jdk/pull/27016/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366474
  Stats: 199 lines in 56 files changed: 3 ins; 0 del; 196 mod
  Patch: https://git.openjdk.org/jdk/pull/27016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27016/head:pull/27016

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

From iklam at openjdk.org  Sat Aug 30 02:27:25 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 30 Aug 2025 02:27:25 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace
Message-ID: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>

Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker.

All changes are mechanical text replacement. Headers are resorted alphabetically.

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

Depends on: https://git.openjdk.org/jdk/pull/27016

Commit messages:
 - Rename MetaspaceShared -> AOTMetaspace

Changes: https://git.openjdk.org/jdk/pull/27017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27017&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366475
  Stats: 356 lines in 56 files changed: 30 ins; 30 del; 296 mod
  Patch: https://git.openjdk.org/jdk/pull/27017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27017/head:pull/27017

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

From kvn at openjdk.org  Sat Aug 30 14:03:47 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 30 Aug 2025 14:03:47 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache()
In-Reply-To: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
Message-ID: <cndvo0pnavFqnTS3TSnvSzGjwpj40dkq-7DwdzYU5RU=.aaa658e2-6059-4f40-8fbe-39a53923a232@github.com>

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

> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
> - tests if an object is inside the AOT cache's metaspace region.
> 
> Also various forms of  "shared metaspace" are updated to "aot metaspace"
> 
> Please start your review with allocations.hpp

src/hotspot/share/include/cds.h line 38:

> 36: // Also, this is a C header file. Do not use C++ here.
> 37: 
> 38: #define NUM_CDS_REGIONS 5 // this must be the same as AOTMetaspace::n_regions

This file changes seems belong to your other RFE JDK-8366475.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27016#discussion_r2311954464

From kvn at openjdk.org  Sat Aug 30 14:03:48 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 30 Aug 2025 14:03:48 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache()
In-Reply-To: <cndvo0pnavFqnTS3TSnvSzGjwpj40dkq-7DwdzYU5RU=.aaa658e2-6059-4f40-8fbe-39a53923a232@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
 <cndvo0pnavFqnTS3TSnvSzGjwpj40dkq-7DwdzYU5RU=.aaa658e2-6059-4f40-8fbe-39a53923a232@github.com>
Message-ID: <L4u-IaXdvg2LFF4_WucNe_qY4MmEN22_NA8hnG2CK8c=.d8737c04-b0fc-4802-ac45-3af658c76807@github.com>

On Sat, 30 Aug 2025 14:01:00 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
>> - tests if an object is inside the AOT cache's metaspace region.
>> 
>> Also various forms of  "shared metaspace" are updated to "aot metaspace"
>> 
>> Please start your review with allocations.hpp
>
> src/hotspot/share/include/cds.h line 38:
> 
>> 36: // Also, this is a C header file. Do not use C++ here.
>> 37: 
>> 38: #define NUM_CDS_REGIONS 5 // this must be the same as AOTMetaspace::n_regions
> 
> This file changes seems belong to your other RFE JDK-8366475.

But I am fine to have it here - it is only in comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27016#discussion_r2311954625

From kvn at openjdk.org  Sat Aug 30 14:08:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 30 Aug 2025 14:08:41 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache()
In-Reply-To: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
Message-ID: <DIzRrKDEFEJW4i8c1bvscN9ZlN_Fs6kkbvcT26Ge8C0=.99d5bbfe-f413-4d6f-89d1-4b3759ad9512@github.com>

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

> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
> - tests if an object is inside the AOT cache's metaspace region.
> 
> Also various forms of  "shared metaspace" are updated to "aot metaspace"
> 
> Please start your review with allocations.hpp

Good. In few places you used `AOTMetaspace` in comments and messages. But I think it is fine. I assume you push this first.

test/hotspot/jtreg/runtime/cds/SpaceUtilizationCheck.java line 62:

> 60:         WhiteBox wb = WhiteBox.getWhiteBox();
> 61:         long reserve_alignment = wb.metaspaceSharedRegionAlignment();
> 62:         System.out.println("AOTMetaspace::core_region_alignment() = " + reserve_alignment);

Here too.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27016#pullrequestreview-3171054693
PR Review Comment: https://git.openjdk.org/jdk/pull/27016#discussion_r2311956105

From kvn at openjdk.org  Sat Aug 30 14:17:45 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 30 Aug 2025 14:17:45 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace
In-Reply-To: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
Message-ID: <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com>

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

> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker.
> 
> All changes are mechanical text replacement. Headers are resorted alphabetically.

Good.

@stefank also asked about `INCLUDE_CDS` to replace it with `INCLUDE_AOT`. Should we do this?

src/hotspot/share/oops/symbol.cpp line 26:

> 24: 
> 25: #include "cds/archiveBuilder.hpp"
> 26: #include "cds/metaspaceShared.hpp"

Do you have usage in this file?

src/hotspot/share/oops/trainingData.cpp line 26:

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

Usage?

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

> 2885:   {CC"incMetaspaceCapacityUntilGC", CC"(J)J",         (void*)&WB_IncMetaspaceCapacityUntilGC },
> 2886:   {CC"metaspaceCapacityUntilGC", CC"()J",             (void*)&WB_MetaspaceCapacityUntilGC },
> 2887:   {CC"metaspaceSharedRegionAlignment", CC"()J",       (void*)&WB_AOTMetaspaceRegionAlignment },

Should you rename `metaspaceSharedRegionAlignment` too?

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

PR Review: https://git.openjdk.org/jdk/pull/27017#pullrequestreview-3171056781
PR Comment: https://git.openjdk.org/jdk/pull/27017#issuecomment-3239296387
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2311958757
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2311958793
PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2311959087

From iklam at openjdk.org  Sat Aug 30 17:34:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 30 Aug 2025 17:34:38 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v2]
In-Reply-To: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
Message-ID: <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>

> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning:
> - tests if an object is inside the AOT cache's metaspace region.
> 
> Also various forms of  "shared metaspace" are updated to "aot metaspace"
> 
> Please start your review with allocations.hpp

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

  Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27016/files
  - new: https://git.openjdk.org/jdk/pull/27016/files/4c68981a..6b8a1b0c

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

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

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

From iklam at openjdk.org  Sat Aug 30 17:37:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 30 Aug 2025 17:37:33 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v2]
In-Reply-To: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
Message-ID: <OSpHiHkfjDVBuNMaavEDbnvrOiD_6MTsh6Ues8m65pA=.9b108e13-9224-4d32-bd2e-019d18474773@github.com>

> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker.
> 
> All changes are mechanical text replacement. Headers are resorted alphabetically.

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

 - Redo changes in comments and tests
 - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace
 - Rename MetaspaceShared -> AOTMetaspace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27017/files
  - new: https://git.openjdk.org/jdk/pull/27017/files/fc63ba0b..0a425935

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

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

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

From iklam at openjdk.org  Sat Aug 30 17:37:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 30 Aug 2025 17:37:42 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v2]
In-Reply-To: <DIzRrKDEFEJW4i8c1bvscN9ZlN_Fs6kkbvcT26Ge8C0=.99d5bbfe-f413-4d6f-89d1-4b3759ad9512@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
 <DIzRrKDEFEJW4i8c1bvscN9ZlN_Fs6kkbvcT26Ge8C0=.99d5bbfe-f413-4d6f-89d1-4b3759ad9512@github.com>
Message-ID: <12PZN2kyxBCAekhzGTgjG8tjTnTp_-uKGgnK6_nQJmU=.142ff531-7701-401b-9eb2-14798a60d920@github.com>

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

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017
>
> test/hotspot/jtreg/runtime/cds/SpaceUtilizationCheck.java line 62:
> 
>> 60:         WhiteBox wb = WhiteBox.getWhiteBox();
>> 61:         long reserve_alignment = wb.metaspaceSharedRegionAlignment();
>> 62:         System.out.println("AOTMetaspace::core_region_alignment() = " + reserve_alignment);
> 
> Here too.

I removed these changes and re-applied them in https://github.com/openjdk/jdk/pull/27017 .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27016#discussion_r2312034141

From iklam at openjdk.org  Sat Aug 30 18:17:43 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 30 Aug 2025 18:17:43 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3]
In-Reply-To: <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
 <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com>
Message-ID: <oBC-ee8D4MiM6AYWwnmX36zK7ovf7fw00t6unhwDR3k=.bd47b141-24ba-421f-afce-e4ea57722835@github.com>

On Sat, 30 Aug 2025 14:12:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed unnecessary includes
>
> src/hotspot/share/prims/whitebox.cpp line 2887:
> 
>> 2885:   {CC"incMetaspaceCapacityUntilGC", CC"(J)J",         (void*)&WB_IncMetaspaceCapacityUntilGC },
>> 2886:   {CC"metaspaceCapacityUntilGC", CC"()J",             (void*)&WB_MetaspaceCapacityUntilGC },
>> 2887:   {CC"metaspaceSharedRegionAlignment", CC"()J",       (void*)&WB_AOTMetaspaceRegionAlignment },
> 
> Should you rename `metaspaceSharedRegionAlignment` too?

I plan to do more renaming in future RFEs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2312044957

From iklam at openjdk.org  Sat Aug 30 18:17:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 30 Aug 2025 18:17:42 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3]
In-Reply-To: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
Message-ID: <wFkxQPaM8Z1B66tQvPvi-DDWbWODU5gwHeYE7OMSsFM=.5853ff2c-2214-44d3-b679-3d9f9fdf84a2@github.com>

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

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

  removed unnecessary includes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27017/files
  - new: https://git.openjdk.org/jdk/pull/27017/files/0a425935..0cadae43

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

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

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

From kvn at openjdk.org  Sat Aug 30 19:47:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 30 Aug 2025 19:47:41 GMT
Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to
 MetaspaceObj::in_aot_cache() [v2]
In-Reply-To: <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
References: <NgVecWqgJJJkgpUCDm6LxKQeTZjkknQ3vTzhMOBWqYE=.de0939e5-cd03-4797-9f20-a4e8d080e030@github.com>
 <d6QOxzI04ySSOZU4HEMyov-oO3bLUC5PZ81wi68kpTo=.61d5671f-6266-4681-81c9-c1c767a057b2@github.com>
Message-ID: <Y11cOL6Q_9AKFNe5ylu_GtGQ9b5bQhOCGh7CTxJDXK8=.5b6aa27a-96f8-4f41-b345-2a2a91b428a0@github.com>

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

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

Update is good.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.org  Sat Aug 30 19:48:42 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 30 Aug 2025 19:48:42 GMT
Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3]
In-Reply-To: <wFkxQPaM8Z1B66tQvPvi-DDWbWODU5gwHeYE7OMSsFM=.5853ff2c-2214-44d3-b679-3d9f9fdf84a2@github.com>
References: <reXc-IB7dzRjjt-TL22PTmKUe0lWEukLYY9RZaZTXrI=.c88176a0-a66a-49b4-b8e5-3a2b4717ae3e@github.com>
 <wFkxQPaM8Z1B66tQvPvi-DDWbWODU5gwHeYE7OMSsFM=.5853ff2c-2214-44d3-b679-3d9f9fdf84a2@github.com>
Message-ID: <_Pwid_3zsEZoZFjGZhCUZniTGzkDyYNCCKzuOfxLVd8=.2e880d87-78d6-4266-958a-caad69d2da1a@github.com>

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

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

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27017#pullrequestreview-3171201064

From dholmes at openjdk.org  Sun Aug 31 21:37:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 31 Aug 2025 21:37:47 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
Message-ID: <XBdP6GOMc7itm_zkl6xFFvgYs2ZO_hgaOKuIyGaoiHA=.7bff7d39-7cb8-405b-a231-ff3f8d7ee9c2@github.com>

On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

Note, before integrating I merged locally with master, checked the incoming changes and re-ran tier 1-3 builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3240430237

From dholmes at openjdk.org  Sun Aug 31 21:37:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 31 Aug 2025 21:37:48 GMT
Subject: Integrated: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <YeeMGoFUJKMyrxnsuN0QH6ZIR1iulNzok8JqoHCxKog=.665b544b-4bb8-4eda-98b8-dcbba78afc10@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

This pull request has now been integrated.

Changeset: 80ab094a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80ab094a75a6474c33214e3347e08ea7b9177ec8
Stats:     202 lines in 46 files changed: 19 ins; 7 del; 176 mod

8347707: Standardise the use of os::snprintf and os::snprintf_checked

Reviewed-by: kbarrett, fbredberg

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

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