From Monica.Beckwith at microsoft.com  Tue Jul  1 01:26:04 2025
From: Monica.Beckwith at microsoft.com (Monica Beckwith)
Date: Tue, 1 Jul 2025 01:26:04 +0000
Subject: RFR: JEP draft: G1: Time-Based Heap Uncommit During Idle Periods
Message-ID: <BY1PR21MB4443DBA80A25B3E52E5106E9E541A@BY1PR21MB4443.namprd21.prod.outlook.com>

Hi all,

I would like to submit "G1: Time-Based Heap Uncommit During Idle Periods" JEP draft [0] for review.

The purpose of this JEP is to enable G1 to automatically uncommit unused memory regions during application idle periods, independent of garbage collection frequency. This brings G1 to parity with ZGC's memory efficiency characteristics while maintaining G1's low-latency and predictable pause time properties.

Key features:
- Periodic background evaluation of heap regions for uncommit eligibility
- Time-based region activity tracking with configurable uncommit delays
- Zero impact on GC pause times through careful synchronization
- Comprehensive JTReg test coverage with boundary conditions and race condition validation

The implementation is complete with extensive testing including 120+ SPECjbb2015 benchmark runs showing 15-45% memory reduction during idle periods with <2% throughput variation.

This enhancement addresses a significant gap in G1's memory efficiency for containerized and cloud-native applications with variable workload patterns. I will link the implementation PR to [0], once submitted. 

Thanks,
Monica

[0] https://bugs.openjdk.org/browse/JDK-8360935

From thomas.schatzl at oracle.com  Tue Jul  1 07:33:49 2025
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 1 Jul 2025 09:33:49 +0200
Subject: RFC: JEP draft: Automatic Heap Sizing for G1
In-Reply-To: <4CD04E2B-1171-4DD7-9C65-F38572867F97@kodewerk.com>
References: <ec32ed1d-7b5b-4085-b572-10711cd328bc@oracle.com>
 <4CD04E2B-1171-4DD7-9C65-F38572867F97@kodewerk.com>
Message-ID: <7d1b05a3-1332-4dc0-af12-de094b243632@oracle.com>

Hi Kirk,

On 27.06.25 16:40, Kirk Pepperdine wrote:
> Hi Thomas,
> 
> I like the proposal. The only questions I have is with regards to the section
 > on "Responding to machine memory pressure? and testing. How do you see
 > testing the features that respond to increased memory pressure?>

   basically we intend to piggyback on what has been done for ZGC so 
far. It basically involves starting the VM in a memory limited 
container, then add some memory consumer (may just be a raw C program 
committing/uncommitting memory over time), and verify that the running 
VM reacts on that.

We may formalize the expected behavior a bit more in some place as the 
implementation matures.

Note that the current extent of this functionality is mostly somewhat 
basic avoidance of OOME for the VMs in e.g. a container.
The VM does not know much about additional requirements like priorities, 
can not divine the intent of the user, etc. so may only fit very simple 
use cases. (Like the "allow potential use of all memory in the 
environment" one).

There is the expectation that users to use the 
*GCIntensity/GCTimeRatio/* controls to implement their own custom 
policies (if they have the need).

Hth,
   Thomas


From tschatzl at openjdk.org  Tue Jul  1 08:18:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Jul 2025 08:18:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
Message-ID: <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>

On Mon, 30 Jun 2025 15:58:07 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update closure name
>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time

Changes requested by tschatzl (Reviewer).

src/hotspot/os/posix/os_posix.cpp line 1603:

> 1601: }
> 1602: 
> 1603: double os::elapsed_process_cpu_time() {

I am kind of conflicted about returning a rounded value (`double`) in that method. There does not seem to be a good reason to not just return the `ns` (integer) value and only do the rounding when presenting the value.

Sorry for not noticing earlier, it's just that recently I did that other change in that area, and the unnecessary effort (and rounding) has been an issue there as well.

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

> 628:     double process_cpu_time = os::elapsed_process_cpu_time();
> 629:     double gc_cpu_time = elapsed_gc_cpu_time();
> 630:     double string_dedup_cpu_time = UseStringDeduplication ? os::thread_cpu_time((Thread*)StringDedup::_processor->_thread) / NANOSECS_PER_SEC : 0;

Just for the record, this is a truncating integer divsion. I do not think this is expected here.

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

> 245:   virtual void stop() = 0;
> 246: 
> 247:   void before_exit();

Now that there is the `before_exit()` method, and `stop()` never called from outside, please make the latter `protected`.
Also, there is no need to make this method virtual any more imo. This could save the three empty overrides (but I can see that one might want to make this abstract for OO pureness). Whatever your decision is here, please change the visibility of `stop()`.

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

> 251:   virtual void safepoint_synchronize_end() {}
> 252: 
> 253:   static jlong vm_cpu_time();

This declaration does not have an implementation (and there is none needed). Please remove.

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

> 294:   static jlong elapsed_frequency();
> 295: 
> 296:   static double elapsed_process_cpu_time();

Not sure if it is required that these methods return their values as `double`s in seconds. Given the uses, this seems unnecessary premature loss of precision.

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2973827814
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176692619
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176602981
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176701530
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176705157
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176605695

From tschatzl at openjdk.org  Tue Jul  1 09:10:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Jul 2025 09:10:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
 <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
Message-ID: <jEBx8vDaTY-FxkRPJRjplZhmiBn6LXyeH5YgAxhTBrc=.b58df2bf-b8ba-421e-a55c-ab5b57ea6532@github.com>

On Tue, 1 Jul 2025 07:45:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update closure name
>>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>
> src/hotspot/os/posix/os_posix.cpp line 1603:
> 
>> 1601: }
>> 1602: 
>> 1603: double os::elapsed_process_cpu_time() {
> 
> I am kind of conflicted about returning a rounded value (`double`) in that method. There does not seem to be a good reason to not just return the `ns` (integer) value and only do the rounding when presenting the value.
> 
> Sorry for not noticing earlier, it's just that recently I did that other change in that area, and the unnecessary effort (and rounding) has been an issue there as well.

Another thought I had was whether the `elapsed` prefix is actually necessary - all cpu times are since thread/process start.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176935618

From duke at openjdk.org  Tue Jul  1 09:35:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 1 Jul 2025 09:35:43 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
 <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
Message-ID: <k9TPvCuyHrJKpUGAOa_TPI_GxG8IUl6zjBPm_EyRNss=.3dfba520-d6cd-44d6-9965-4a0bdb7e63d8@github.com>

On Tue, 1 Jul 2025 07:08:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update closure name
>>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>
> src/hotspot/share/runtime/os.hpp line 296:
> 
>> 294:   static jlong elapsed_frequency();
>> 295: 
>> 296:   static double elapsed_process_cpu_time();
> 
> Not sure if it is required that these methods return their values as `double`s in seconds. Given the uses, this seems unnecessary premature loss of precision.

It is not required, but I was conforming to the same type as the methods that was removed in JDK-8274051 and as well as `elapsedTime()`. `elapsedTime()` returns the wall-clock time in seconds since start in `double`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2177009372

From duke at openjdk.org  Tue Jul  1 09:48:59 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 1 Jul 2025 09:48:59 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v13]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <81zhYMzwafmk-EFXUn2z0ZUdjVTvjJUr_v9aXI8Hq2g=.8f8edc4c-488a-4452-818f-457305f52bb1@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

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

  Make stop protected, remove integer divison, remove unused method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/35a74668..38841dc9

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

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

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

From ayang at openjdk.org  Tue Jul  1 10:16:48 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 1 Jul 2025 10:16:48 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v4]
In-Reply-To: <9rBfmwlk3NgNPtcbwQduzm143Rj8JqZFPp2091Uo-EM=.06209243-d0d2-484f-84df-e73d8ba36926@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
 <9rBfmwlk3NgNPtcbwQduzm143Rj8JqZFPp2091Uo-EM=.06209243-d0d2-484f-84df-e73d8ba36926@github.com>
Message-ID: <BqDh0As7aFihuWM7aAXZLel1-8bzFviJSZ0eiIsI18E=.e01152ed-c72e-4e80-b042-b0059bdf0955@github.com>

On Fri, 27 Jun 2025 19:01:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang 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:
> 
>  - Merge branch 'master' into ref-refactor
>  - review
>  - review
>  - Merge branch 'master' into ref-refactor
>  - Merge branch 'master' into ref-refactor
>  - ref-refactor

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25930#issuecomment-3023165803

From ayang at openjdk.org  Tue Jul  1 10:16:48 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 1 Jul 2025 10:16:48 GMT
Subject: Integrated: 8360206: Refactor ReferenceProcessor::balance_queues
In-Reply-To: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
Message-ID: <Ulegn_wTuqAzxLVMEGKhv8niSLYqa6FtpI8LWDswOBA=.cb9addf8-fb4c-4592-8c20-8b4d7325f283@github.com>

On Mon, 23 Jun 2025 08:30:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
> 
> Test: tier1-3

This pull request has now been integrated.

Changeset: fc739fee
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fc739fee5360ec052c2b51b3e30ce1c34df71714
Stats:     62 lines in 1 file changed: 11 ins; 12 del; 39 mod

8360206: Refactor ReferenceProcessor::balance_queues

Reviewed-by: sangheki, kbarrett, tschatzl

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

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

From ayang at openjdk.org  Tue Jul  1 10:17:49 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 1 Jul 2025 10:17:49 GMT
Subject: RFR: 8361056: Parallel: Use correct is_par argument in
 ScavengeRootsTask
In-Reply-To: <TVTW4V_C_qEGLgomaiZjjn2JDFMqT3VNLhi8308t8f4=.e045344b-588b-46b4-bc7f-25ca9f7af485@github.com>
References: <TVTW4V_C_qEGLgomaiZjjn2JDFMqT3VNLhi8308t8f4=.e045344b-588b-46b4-bc7f-25ca9f7af485@github.com>
Message-ID: <DdezCBZbcrt2cA_3lrw7XIzXqWyfO5YY5bVCBqY1fRA=.6421da9c-bf0c-4dbf-938e-aa72f2d9f0aa@github.com>

On Mon, 30 Jun 2025 08:37:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial fixing the hardcoded `is_par` arg used during young-gc.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26039#issuecomment-3023168330

From ayang at openjdk.org  Tue Jul  1 10:17:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 1 Jul 2025 10:17:50 GMT
Subject: Integrated: 8361056: Parallel: Use correct is_par argument in
 ScavengeRootsTask
In-Reply-To: <TVTW4V_C_qEGLgomaiZjjn2JDFMqT3VNLhi8308t8f4=.e045344b-588b-46b4-bc7f-25ca9f7af485@github.com>
References: <TVTW4V_C_qEGLgomaiZjjn2JDFMqT3VNLhi8308t8f4=.e045344b-588b-46b4-bc7f-25ca9f7af485@github.com>
Message-ID: <hWVYYZy1Zhbn8597QKZ93vok_AFaFaeg4gQEdLxutzQ=.036f11da-78f3-4b7d-aecc-7080e6b5b684@github.com>

On Mon, 30 Jun 2025 08:37:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial fixing the hardcoded `is_par` arg used during young-gc.

This pull request has now been integrated.

Changeset: eec11539
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eec1153993a2a6e65b05e6d9d7416ee0cb634503
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361056: Parallel: Use correct is_par argument in ScavengeRootsTask

Reviewed-by: tschatzl

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

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

From ayang at openjdk.org  Tue Jul  1 10:23:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 1 Jul 2025 10:23:45 GMT
Subject: RFR: 8360790: G1: Improve HRRSStatsIter name
In-Reply-To: <us20YzLggddyDsPIb9n4AC2LtKSXSly6dRV7hC02YMw=.36197243-27ed-4ce3-ba2e-7f8cbc25f7cd@github.com>
References: <us20YzLggddyDsPIb9n4AC2LtKSXSly6dRV7hC02YMw=.36197243-27ed-4ce3-ba2e-7f8cbc25f7cd@github.com>
Message-ID: <TIYAMkI81DhE_QnBrIT6bvRiky5CrSkOcK1HlDDQMn4=.87e8d32d-6e87-4ea9-b40d-68f7da6a6d5c@github.com>

On Mon, 30 Jun 2025 11:32:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that changes the names of some internal classes related to remembered set summaries to use the G1 prefix.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26042#pullrequestreview-2974716491

From tschatzl at openjdk.org  Tue Jul  1 10:42:50 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Jul 2025 10:42:50 GMT
Subject: RFR: 8360790: G1: Improve HRRSStatsIter name
In-Reply-To: <VIPjRQssHVQrpesG1ywBhFvOWRvwJTA9gYcYTnc7rvc=.13cd7ee6-cae0-4e54-bc3e-04b0edcd4263@github.com>
References: <us20YzLggddyDsPIb9n4AC2LtKSXSly6dRV7hC02YMw=.36197243-27ed-4ce3-ba2e-7f8cbc25f7cd@github.com>
 <VIPjRQssHVQrpesG1ywBhFvOWRvwJTA9gYcYTnc7rvc=.13cd7ee6-cae0-4e54-bc3e-04b0edcd4263@github.com>
Message-ID: <GIiEY5ZZgteJZI83Xnwyw8pVWoOdtJnprAE872SG9sE=.e91525c9-1b12-4b18-aa29-16b2326758e6@github.com>

On Mon, 30 Jun 2025 16:08:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that changes the names of some internal classes related to remembered set summaries to use the G1 prefix.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> I particularly approve of HRRSStatsIter => G1HeapRegionStatsClosure.
> 
> Looks good.

Thanks @kimbarrett @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26042#issuecomment-3023315621

From tschatzl at openjdk.org  Tue Jul  1 10:42:51 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Jul 2025 10:42:51 GMT
Subject: Integrated: 8360790: G1: Improve HRRSStatsIter name
In-Reply-To: <us20YzLggddyDsPIb9n4AC2LtKSXSly6dRV7hC02YMw=.36197243-27ed-4ce3-ba2e-7f8cbc25f7cd@github.com>
References: <us20YzLggddyDsPIb9n4AC2LtKSXSly6dRV7hC02YMw=.36197243-27ed-4ce3-ba2e-7f8cbc25f7cd@github.com>
Message-ID: <65n_vPH0ADTgGMYxhXLmCyGUyPqFifgDFZvctn6ru7o=.cfbd4b16-2230-4165-b7bb-e43447664c06@github.com>

On Mon, 30 Jun 2025 11:32:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that changes the names of some internal classes related to remembered set summaries to use the G1 prefix.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: e85c7d09
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e85c7d09df67728ddcf852a96e5b2baa57c502f1
Stats:     18 lines in 1 file changed: 0 ins; 1 del; 17 mod

8360790: G1: Improve HRRSStatsIter name

Reviewed-by: kbarrett, ayang

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

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

From mhaessig at openjdk.org  Tue Jul  1 11:27:49 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 1 Jul 2025 11:27:49 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
Message-ID: <U2pkrbJtCOAswOM9iXx8kEf2FQuQZDgedCpf0ZHreh0=.f519ca6c-aa4a-465b-9e11-825c9071afc8@github.com>

On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8358821-patch-verified-entry
>  - 2nd try at arm fix
>  - rename arm_with to guard_with
>  - arm32 fix
>  - s390 fix courtesy of Amit Kumar
>  - remove is_sigill_not_entrant
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

Backing out #24831 sounds reasonable to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3023516324

From ayang at openjdk.org  Tue Jul  1 11:37:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 1 Jul 2025 11:37:43 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v9]
In-Reply-To: <24IBqFegflzzJC1jB1t7LFUasQXD59KqTefhtGq71PU=.0dbe6333-bb7b-415f-aa68-b8eeede95627@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <24IBqFegflzzJC1jB1t7LFUasQXD59KqTefhtGq71PU=.0dbe6333-bb7b-415f-aa68-b8eeede95627@github.com>
Message-ID: <dMLILFioWq8Cs_AhhQpKJRUGHO5Q7Ak2nFqbUdLE10c=.09509e58-11d8-4229-8a25-7f3065a0ad90@github.com>

On Mon, 30 Jun 2025 12:42:11 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 1453:

> 1451:     _g1h->increment_total_collections();
> 1452: 
> 1453:     if (_g1h->last_gc_was_periodic()) {

Could you add some comment why this checking is needed? (It's not obvious from the context.)

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 175:

> 173:   assert(cpu_usage_delta >= 0.0, "must be");
> 174: 
> 175:   const double min_scale_factor = G1ShrinkByPercentOfAvailable / 1000.0;

I wonder if this can be written as `min = max / 10`. At first glance, I thought it's a typo, `1000` instead of `100`, but the key msg is that min is 1/10 of max (next line), right?

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 41:

> 39: // GC CPU usage set by the user.
> 40: //
> 41: // The heuristics track both short and long term GC behavior to effect heap resizing.

Typo: "effect" -> "affect".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2177256550
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2177293569
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2177317790

From duke at openjdk.org  Tue Jul  1 12:03:08 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 1 Jul 2025 12:03:08 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [1.563s][info][gc,cpu] GC CPU usage: 42.26%

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

  Change output per discussion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/38841dc9..3104ff6a

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

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

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

From iwalulya at openjdk.org  Tue Jul  1 12:33:22 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 1 Jul 2025 12:33:22 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v10]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <435Jyl8OLAtEIrTNAp151LApVhXiN-2D_Xfhnm9sOvA=.77728335-e46f-4bfe-808b-ae1593b5fdd7@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

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

  Albert suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25832/files
  - new: https://git.openjdk.org/jdk/pull/25832/files/88434073..b62c827e

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

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

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

From tschatzl at openjdk.org  Tue Jul  1 13:10:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Jul 2025 13:10:41 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
Message-ID: <j444ENcLHx-f7jhEZjVKzAXVljb5Wi-u1QtWUfIwZ4g=.93d898f6-90da-460b-bf07-8b50249d06a6@github.com>

On Tue, 1 Jul 2025 12:03:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [1.563s][info][gc,cpu] GC CPU usage: 42.26%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change output per discussion

lgtm

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2975373548

From duke at openjdk.org  Tue Jul  1 13:27:45 2025
From: duke at openjdk.org (duke)
Date: Tue, 1 Jul 2025 13:27:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
Message-ID: <AT_pt4kQJ6Q2x0KKHqr5FWZzES0Uve6wQn3eWU02dLQ=.5ace16b9-1a88-4c74-b7e9-aab713be6fb2@github.com>

On Tue, 1 Jul 2025 12:03:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [1.563s][info][gc,cpu] GC CPU usage: 42.26%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change output per discussion

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

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3024012582

From tschatzl at openjdk.org  Wed Jul  2 07:03:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 2 Jul 2025 07:03:47 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v10]
In-Reply-To: <TLXICoci5pVVNQU2vs0eBEWs95Vgpj-o0IKcjgYFgcs=.58f537ca-0b87-4704-b692-8ab20f659c0e@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
 <TLXICoci5pVVNQU2vs0eBEWs95Vgpj-o0IKcjgYFgcs=.58f537ca-0b87-4704-b692-8ab20f659c0e@github.com>
Message-ID: <9m4YNoOw_rp9t4ohninQDMbzc_-18rZBVQNvxMQCFSM=.c624e95c-39bf-4693-9331-a7a1f5d44484@github.com>

On Tue, 17 Jun 2025 12:52:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert suggestions
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 894:
> 
>> 892: 
>> 893:   bool should_expand;
>> 894:   size_t resize_bytes = _heap_sizing_policy->full_collection_resize_amount(should_expand, allocation_word_size);
> 
> pre-existing:  I wonder why this isn't a function that returns a `ptrdiff_t` delta on the current size,
> removing the need for multiple values, one being returned via a by-reference out parameter.
> Similarly for the young collection case. Or return the size & direction as a pair-like object.
> (Personally, I find by-reference out parameters confusing to read, but maybe that's just me.)

One potential reason: on 32 bit platforms `ptrdiff_t` is +- 2GB. Heap can be ~4GB on Linux, so `ptrdiff_t` could not represent all potential resize sizes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2179279576

From dholmes at openjdk.org  Wed Jul  2 07:25:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 07:25:43 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <k9TPvCuyHrJKpUGAOa_TPI_GxG8IUl6zjBPm_EyRNss=.3dfba520-d6cd-44d6-9965-4a0bdb7e63d8@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
 <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
 <k9TPvCuyHrJKpUGAOa_TPI_GxG8IUl6zjBPm_EyRNss=.3dfba520-d6cd-44d6-9965-4a0bdb7e63d8@github.com>
Message-ID: <y--qiGOt06nNV75zVSiyiy_TQVqTV4HvtB72_BrNmc0=.6e12feae-cd88-4d0c-a52b-50fe359861c9@github.com>

On Tue, 1 Jul 2025 09:33:26 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.hpp line 296:
>> 
>>> 294:   static jlong elapsed_frequency();
>>> 295: 
>>> 296:   static double elapsed_process_cpu_time();
>> 
>> Not sure if it is required that these methods return their values as `double`s in seconds. Given the uses, this seems unnecessary premature loss of precision.
>
> It is not required, but I was conforming to the same type as the methods that was removed in JDK-8274051 and as well as `elapsedTime()`. `elapsedTime()` returns the wall-clock time in seconds since start in `double`.

I don't see how there is a loss of precision here, just because the unit ahead of the decimal point is seconds. 

2.123456789 seconds still has nanosecond precision

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179319901

From dholmes at openjdk.org  Wed Jul  2 07:38:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 07:38:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
Message-ID: <v2hXWian6z-9A95u1KFlKuo6v-f2FrKfs-wmfqo36rI=.579bb7da-3179-488f-9c70-0695a9b0d456@github.com>

On Tue, 1 Jul 2025 12:03:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change output per discussion

@JonasNorlinder  you need two reviews before integrating hotspot changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3026784458

From eosterlund at openjdk.org  Wed Jul  2 08:19:49 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 2 Jul 2025 08:19:49 GMT
Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be
 disarmed
In-Reply-To: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
References: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
Message-ID: <POrGDvdm7F0UvSy3Wu33s8j_aAsUTRfWm2c6nStHX8w=.0228f812-b820-4491-b009-dd121fa6ea37@github.com>

On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed.
> 
> I will need reviews from GC experts to check for potentially problematic side effects.
> Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now.
> 
> Some stats (nmethod entry barrier hits in jvm98 with/without patch):
> 
> | GC       | before | after |
> | -------- | ------ | ----- |
> | G1       |   3339 |   127 |
> | Parallel |   3223 |  1141 |
> | Serial   |   3206 |  1142 |

This looks fine to me. The oops should be alive, and _gc_epoch is looking right.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25982#pullrequestreview-2978195984

From tschatzl at openjdk.org  Wed Jul  2 08:50:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 2 Jul 2025 08:50:52 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <y--qiGOt06nNV75zVSiyiy_TQVqTV4HvtB72_BrNmc0=.6e12feae-cd88-4d0c-a52b-50fe359861c9@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
 <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
 <k9TPvCuyHrJKpUGAOa_TPI_GxG8IUl6zjBPm_EyRNss=.3dfba520-d6cd-44d6-9965-4a0bdb7e63d8@github.com>
 <y--qiGOt06nNV75zVSiyiy_TQVqTV4HvtB72_BrNmc0=.6e12feae-cd88-4d0c-a52b-50fe359861c9@github.com>
Message-ID: <GFlsWYyYqofynitxxCBikwUO0UJ_cA2X3HPDQ4BFs0k=.37c9a87d-8de3-4a5d-9cea-71d236d53ac4@github.com>

On Wed, 2 Jul 2025 07:22:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It is not required, but I was conforming to the same type as the methods that was removed in JDK-8274051 and as well as `elapsedTime()`. `elapsedTime()` returns the wall-clock time in seconds since start in `double`.
>
> I don't see how there is a loss of precision here, just because the unit ahead of the decimal point is seconds. 
> 
> 2.123456789 seconds still has nanosecond precision

Instead of adding integer nanosecond values together to form a final sum and then divide just when printing the value, the code divides each part of the sum  and then add them together. The FP division is lossy due to (very minor) representation issues too.

Also performs unnecessary relatively costly FP operations.

Very negligible nowadays, but why incur these problems for no reason? There does not seem to be an advantage to keep intermediate values as doubles in seconds.

It's far from a blocker from me, in fact I already signed this off.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179489841

From tschatzl at openjdk.org  Wed Jul  2 09:15:51 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 2 Jul 2025 09:15:51 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
Message-ID: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>

Hi all,

  please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.

The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.

In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8361238

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

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

From iwalulya at openjdk.org  Wed Jul  2 09:27:46 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 2 Jul 2025 09:27:46 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
Message-ID: <p0oM0BFSTgasCSc_qLFVl0P-RPZXcefFbCGhvrZnit8=.805a1924-70c5-4508-9e08-e4c57dcf4cbf@github.com>

On Mon, 30 Jun 2025 10:24:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

LGTM! very nice overhaul.

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2978420691

From mdoerr at openjdk.org  Wed Jul  2 09:32:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 09:32:38 GMT
Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be
 disarmed
In-Reply-To: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
References: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
Message-ID: <T1Ry1sVu4tvhpne1c7HN5k21HPT0PvPlvsnCXC4RXeE=.3dd13acf-19c2-49c8-8610-07079fdda905@github.com>

On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed.
> 
> I will need reviews from GC experts to check for potentially problematic side effects.
> Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now.
> 
> Some stats (nmethod entry barrier hits in jvm98 with/without patch):
> 
> | GC       | before | after |
> | -------- | ------ | ----- |
> | G1       |   3339 |   127 |
> | Parallel |   3223 |  1141 |
> | Serial   |   3206 |  1142 |

Thanks for the review! I hope we can find somebody for a 2nd review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3027142576

From ayang at openjdk.org  Wed Jul  2 10:07:18 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 2 Jul 2025 10:07:18 GMT
Subject: RFR: 8361204: Parallel: Skip visiting per-thread nmethods during young
 GC
Message-ID: <RIjiddsyzUfQWDTLCMdogWA8YM7ghZbGgkUKaZtABhQ=.75c0938c-bf51-4c79-9076-90a15d5aa7c0@github.com>

Small patch of removing per-thread nmethod visiting during young-gc, because relevant nmethods for young-gc are already tracked by `ScavengableNMethods`.

Test: tier1-8

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

Commit messages:
 - pgc-skip-nmethod

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

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

From azeller at openjdk.org  Wed Jul  2 11:07:39 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Wed, 2 Jul 2025 11:07:39 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
In-Reply-To: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
Message-ID: <hetZYi6kpVG1nJrK9IcQlix5MIE4N0JsY_MrHd2wfvY=.8f435f33-859f-4e6e-9786-cd642c08fd89@github.com>

On Wed, 2 Jul 2025 07:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
> 
> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
> 
> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good to me - just verified that it solves the issues we have seen on AIX in tier1 tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/26086#issuecomment-3027438351

From ayang at openjdk.org  Wed Jul  2 11:26:49 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 2 Jul 2025 11:26:49 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
Message-ID: <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>

On Tue, 1 Jul 2025 12:03:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change output per discussion

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

> 209: public:
> 210:   virtual void do_thread(Thread* thread) {
> 211:     Atomic::add(&_cpu_time, os::thread_cpu_time(thread));

Should we check for `-1` here?

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

> 628:     double process_cpu_time = os::elapsed_process_cpu_time();
> 629:     double gc_cpu_time = elapsed_gc_cpu_time();
> 630:     double string_dedup_cpu_time = UseStringDeduplication ? (double)os::thread_cpu_time((Thread*)StringDedup::_processor->_thread) / NANOSECS_PER_SEC : 0;

If we consider stringdedup as gc-time, should this line be inlined to `elapsed_gc_cpu_time`?

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

> 632:     if (process_cpu_time == -1 || gc_cpu_time == -1 || string_dedup_cpu_time == -1) {
> 633:       return;
> 634:     }

Should there be a warning-log here?

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

> 133:   NOT_PRODUCT(volatile size_t _promotion_failure_alot_gc_number;)
> 134: 
> 135:   static jlong _vmthread_cpu_time;

I wonder if it's more natural to make it non-static.

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

> 210: 
> 211:   // Stop any onging concurrent work and prepare for exit.
> 212:   virtual void stop() = 0;

Why `= 0` instead of `{}` as before?

src/hotspot/share/gc/z/zCollectedHeap.cpp line 25:

> 23: 
> 24: #include "classfile/classLoaderData.hpp"
> 25: #include "gc/shared/collectedHeap.inline.hpp"

Seems unneeded.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179799665
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179801486
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179791109
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179805696
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179792124
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179781501

From kbarrett at openjdk.org  Wed Jul  2 13:37:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 13:37:39 GMT
Subject: RFR: 8338474: Parallel: Deprecate and obsolete PSChunkLargeArrays
In-Reply-To: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
References: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
Message-ID: <R409R4V8IbaDubiyyNeuc8f1lpl-DxM8a-K49_z451k=.00052370-bae4-43c0-87b2-6901ceb9426f@github.com>

On Thu, 26 Jun 2025 09:55:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `PSChunkLargeArrays`, which is used only by Parallel and it is enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number of commandline flags.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25997#pullrequestreview-2979199847

From ayang at openjdk.org  Wed Jul  2 13:42:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 2 Jul 2025 13:42:45 GMT
Subject: RFR: 8338474: Parallel: Deprecate and obsolete PSChunkLargeArrays
In-Reply-To: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
References: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
Message-ID: <V1C_Hd2vVz19885kTYUyd9vgdrOMenLqWl5QwNmiGwM=.44839b51-87d1-4e7a-9435-5309b6fe806c@github.com>

On Thu, 26 Jun 2025 09:55:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `PSChunkLargeArrays`, which is used only by Parallel and it is enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number of commandline flags.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25997#issuecomment-3027924284

From ayang at openjdk.org  Wed Jul  2 13:42:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 2 Jul 2025 13:42:45 GMT
Subject: Integrated: 8338474: Parallel: Deprecate and obsolete
 PSChunkLargeArrays
In-Reply-To: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
References: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
Message-ID: <AQ7P3na4FSD_Q9ZtQWTWUMyipd-6yXex6TFjlmqdX44=.12b5bf3d-7281-4e8a-a94f-6e505f14dc95@github.com>

On Thu, 26 Jun 2025 09:55:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `PSChunkLargeArrays`, which is used only by Parallel and it is enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number of commandline flags.

This pull request has now been integrated.

Changeset: 832bfbc0
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/832bfbc0ddcf3068bab5d45d361803152736383f
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8338474: Parallel: Deprecate and obsolete PSChunkLargeArrays

Reviewed-by: tschatzl, kbarrett

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

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

From ayang at openjdk.org  Wed Jul  2 15:30:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 2 Jul 2025 15:30:40 GMT
Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be
 disarmed
In-Reply-To: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
References: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
Message-ID: <2diqYIb4wOwfPVEFi_s5N9-IAEPwQoeKxxTkj6JoILo=.ec8b3da9-8481-44cc-86ae-d8d99797e5c3@github.com>

On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Note that rebuild_code_roots() disarms all nmethods during G1FullCollector::complete_collection, now.

Would that interfere with the coldness estimate?


  // 2. Used at the end of (stw/concurrent) marking so that nmethod::_gc_epoch
  //    is up-to-date, which provides more accurate estimate of
  //    nmethod::is_cold.
  static void arm_all_nmethods();

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

PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3028304664

From kbarrett at openjdk.org  Wed Jul  2 16:01:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 16:01:51 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
In-Reply-To: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
Message-ID: <TtVXe7euoWy7WsdodfkunCom9wYCvm1xSBS8Q1_0U4g=.906c71f4-cfa0-4ca1-9ab6-5a26955df25b@github.com>

On Wed, 2 Jul 2025 07:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
> 
> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
> 
> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26086#pullrequestreview-2979755321

From duke at openjdk.org  Wed Jul  2 16:35:45 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 2 Jul 2025 16:35:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
Message-ID: <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>

On Wed, 2 Jul 2025 11:22:08 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:
>> 
>>   Change output per discussion
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 630:
> 
>> 628:     double process_cpu_time = os::elapsed_process_cpu_time();
>> 629:     double gc_cpu_time = elapsed_gc_cpu_time();
>> 630:     double string_dedup_cpu_time = UseStringDeduplication ? (double)os::thread_cpu_time((Thread*)StringDedup::_processor->_thread) / NANOSECS_PER_SEC : 0;
> 
> If we consider stringdedup as gc-time, should this line be inlined to `elapsed_gc_cpu_time`?

I'd prefer not to, as it is strictly not GC-time and we may want to use these methods in other places in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180503221

From mdoerr at openjdk.org  Wed Jul  2 16:40:39 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 16:40:39 GMT
Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be
 disarmed
In-Reply-To: <2diqYIb4wOwfPVEFi_s5N9-IAEPwQoeKxxTkj6JoILo=.ec8b3da9-8481-44cc-86ae-d8d99797e5c3@github.com>
References: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
 <2diqYIb4wOwfPVEFi_s5N9-IAEPwQoeKxxTkj6JoILo=.ec8b3da9-8481-44cc-86ae-d8d99797e5c3@github.com>
Message-ID: <Qip0F848yHkUeAS95NJnGDcUyIcBOtwFF20Jg5PNtNM=.83ad5b22-2c04-4783-b17c-bba8e7a1b191@github.com>

On Wed, 2 Jul 2025 15:27:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> G1FullCollector::complete_collection

`complete_collection` happens after `G1CollectedHeap::finish_codecache_marking_cycle()`, so updating all nmethods sounds good to me. But this is actually what I'd like to have double-checked.

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

PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3028528067

From duke at openjdk.org  Wed Jul  2 16:50:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 2 Jul 2025 16:50:43 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
Message-ID: <33ZNj2C1QBn0aj20urwxjuyokqysfQVJQ6P9YWI8-B0=.73b336fa-e00c-4705-96ff-5385c3f8ba54@github.com>

On Wed, 2 Jul 2025 11:24:09 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:
>> 
>>   Change output per discussion
>
> src/hotspot/share/gc/shared/collectedHeap.hpp line 135:
> 
>> 133:   NOT_PRODUCT(volatile size_t _promotion_failure_alot_gc_number;)
>> 134: 
>> 135:   static jlong _vmthread_cpu_time;
> 
> I wonder if it's more natural to make it non-static.

Could you please elaborate? Other variables like `static size_t _stack_chunk_max_size` is also static.

> src/hotspot/share/gc/shared/collectedHeap.hpp line 212:
> 
>> 210: 
>> 211:   // Stop any onging concurrent work and prepare for exit.
>> 212:   virtual void stop() = 0;
> 
> Why `= 0` instead of `{}` as before?

It was suggested by @stefank in above discussions. https://github.com/openjdk/jdk/pull/25779#discussion_r2162341225 Is this something you think we should revert?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180532088
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180534726

From duke at openjdk.org  Wed Jul  2 17:01:28 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 2 Jul 2025 17:01:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v15]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <8CI578A5O8a_0TRQq7PXcHppypgvYSl9RiLtlUAeBpo=.8930c53e-ecc8-4102-9daa-b3944acccb48@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  Fixes after @albertnetymk review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/3104ff6a..08093057

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=13-14

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

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

From sangheki at openjdk.org  Thu Jul  3 00:19:38 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Thu, 3 Jul 2025 00:19:38 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
In-Reply-To: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
Message-ID: <PcrhYnlgWjCxBp55U1vcNBfhuM8f8Sm7b2OfFGeLXzQ=.9c08b4df-a678-4387-a3f6-e8fa651bdb0a@github.com>

On Wed, 2 Jul 2025 07:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
> 
> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
> 
> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

LGTM

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

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26086#pullrequestreview-2981003924

From ayang at openjdk.org  Thu Jul  3 06:40:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 06:40:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
 <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>
Message-ID: <xXn0o0rIwotlmlz4_Akcte9dFM2-__VOk9XIva7EJ8E=.6f86fecb-a8c6-4b67-abac-958eee215f12@github.com>

On Wed, 2 Jul 2025 16:32:31 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/collectedHeap.cpp line 630:
>> 
>>> 628:     double process_cpu_time = os::elapsed_process_cpu_time();
>>> 629:     double gc_cpu_time = elapsed_gc_cpu_time();
>>> 630:     double string_dedup_cpu_time = UseStringDeduplication ? (double)os::thread_cpu_time((Thread*)StringDedup::_processor->_thread) / NANOSECS_PER_SEC : 0;
>> 
>> If we consider stringdedup as gc-time, should this line be inlined to `elapsed_gc_cpu_time`?
>
> I'd prefer not to, as it is strictly not GC-time and we may want to use these methods in other places in the future.

That would result into inconsistency, because we surely treat them as gc-time here. It'd be super confusing if the def of gc-time is not coherent inside JVM.

>> src/hotspot/share/gc/shared/collectedHeap.hpp line 135:
>> 
>>> 133:   NOT_PRODUCT(volatile size_t _promotion_failure_alot_gc_number;)
>>> 134: 
>>> 135:   static jlong _vmthread_cpu_time;
>> 
>> I wonder if it's more natural to make it non-static.
>
> Could you please elaborate? Other variables like `static size_t _stack_chunk_max_size` is also static.

This class contains both static and non-static fields. Since `_vmthread_cpu_time` is accessed in `elapsed_gc_cpu_time` (non-static), I tend to think it should be non-static. (`add_vmthread_cpu_time` is static, but its sole caller actually use the instance, i.e. dropping the static for it still compiles.)

>> src/hotspot/share/gc/shared/collectedHeap.hpp line 212:
>> 
>>> 210: 
>>> 211:   // Stop any onging concurrent work and prepare for exit.
>>> 212:   virtual void stop() = 0;
>> 
>> Why `= 0` instead of `{}` as before?
>
> It was suggested by @stefank in above discussions. https://github.com/openjdk/jdk/pull/25779#discussion_r2162341225 Is this something you think we should revert?

I understand the part of splitting it into two methods, but why making it pure-virtual? Wouldn't `{}` as before work?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180979113
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180969511
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180975563

From ayang at openjdk.org  Thu Jul  3 06:42:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 06:42:39 GMT
Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be
 disarmed
In-Reply-To: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
References: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
Message-ID: <hxRSfk3uT3zShFjPh9ad0QdOiHhpLA_kdfph_v4sQOo=.6b543b28-8d90-4651-a636-808e832a9c74@github.com>

On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed.
> 
> I will need reviews from GC experts to check for potentially problematic side effects.
> Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now.
> 
> Some stats (nmethod entry barrier hits in jvm98 with/without patch):
> 
> | GC       | before | after |
> | -------- | ------ | ----- |
> | G1       |   3339 |   127 |
> | Parallel |   3223 |  1141 |
> | Serial   |   3206 |  1142 |

My understanding on how arming-at-marking-end works is that java threads will hit those armed nmethods after full-gc-pause-end, run nmethod-entry-barrier, and mark them as "hot" (`mark_as_maybe_on_stack`), then in the next full-gc, unloading logic will identify those "hot" nmethods and not unload them. IOW, we use the btw-full-gc window to measure nmethod-temperature.

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

PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3031053820

From tschatzl at openjdk.org  Thu Jul  3 07:01:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 07:01:53 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
In-Reply-To: <TtVXe7euoWy7WsdodfkunCom9wYCvm1xSBS8Q1_0U4g=.906c71f4-cfa0-4ca1-9ab6-5a26955df25b@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
 <TtVXe7euoWy7WsdodfkunCom9wYCvm1xSBS8Q1_0U4g=.906c71f4-cfa0-4ca1-9ab6-5a26955df25b@github.com>
Message-ID: <E8M2JruuLu3ByeD4-Exf_KB7Qyq8wSceBxa5HXfeWnc=.d8bd2b16-6832-4052-8b45-d5315e96f3dd@github.com>

On Wed, 2 Jul 2025 15:58:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
>> 
>> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
>> 
>> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Looks good.

Thanks @kimbarrett @sangheon for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26086#issuecomment-3031103688

From tschatzl at openjdk.org  Thu Jul  3 07:01:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 07:01:54 GMT
Subject: Integrated: 8361238: G1 tries to get CPU info from terminated threads
 at shutdown
In-Reply-To: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
Message-ID: <ORA3SqPqj-uklmgHI9C7ioxlYK-i1Wh2i1KHgHDWM6Q=.22beb082-d431-4f20-bd82-1674829dcc9e@github.com>

On Wed, 2 Jul 2025 07:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
> 
> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
> 
> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 6c9236c8
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c9236c80c236487a7c37dcb947c0f9192322208
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8361238: G1 tries to get CPU info from terminated threads at shutdown

Reviewed-by: kbarrett, sangheki

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

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

From duke at openjdk.org  Thu Jul  3 07:15:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 07:15:43 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <xXn0o0rIwotlmlz4_Akcte9dFM2-__VOk9XIva7EJ8E=.6f86fecb-a8c6-4b67-abac-958eee215f12@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
 <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>
 <xXn0o0rIwotlmlz4_Akcte9dFM2-__VOk9XIva7EJ8E=.6f86fecb-a8c6-4b67-abac-958eee215f12@github.com>
Message-ID: <o2HJ-mJZUvdhlLJUj2IFJScbBnZC1I6H2lMuGrM3JC0=.4e7ef168-3bb4-486b-a9bb-8fb2602e3985@github.com>

On Wed, 2 Jul 2025 21:11:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I'd prefer not to, as it is strictly not GC-time and we may want to use these methods in other places in the future.
>
> That would result into inconsistency, because we surely treat them as gc-time here. It'd be super confusing if the def of gc-time is not coherent inside JVM.

OK, if we ever want to report these separately we can deal with that then. I will move it.

>> It was suggested by @stefank in above discussions. https://github.com/openjdk/jdk/pull/25779#discussion_r2162341225 Is this something you think we should revert?
>
> I understand the part of splitting it into two methods, but why making it pure-virtual? Wouldn't `{}` as before work?

Both works. I believe it was a stylistic choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182033010
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182034682

From duke at openjdk.org  Thu Jul  3 07:36:02 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 07:36:02 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v16]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <oXU0PCFvdFMsAk0_0fJxydUm_poeQIXoIljfr_7zNTc=.1b69c062-3f69-4314-ab9a-68fc2946bf5a@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/08093057..d4c7c69b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=14-15

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

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

From tschatzl at openjdk.org  Thu Jul  3 07:38:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 07:38:40 GMT
Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be
 disarmed
In-Reply-To: <hxRSfk3uT3zShFjPh9ad0QdOiHhpLA_kdfph_v4sQOo=.6b543b28-8d90-4651-a636-808e832a9c74@github.com>
References: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>
 <hxRSfk3uT3zShFjPh9ad0QdOiHhpLA_kdfph_v4sQOo=.6b543b28-8d90-4651-a636-808e832a9c74@github.com>
Message-ID: <Zx7j7ZAaC9_yaymmYDAWbDSQEfUpIB7Dwn2VAyZR1To=.1a14cef6-25db-483c-b5d9-45c71e2d9e44@github.com>

On Thu, 3 Jul 2025 06:39:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> My understanding on how arming-at-marking-end works is that java threads will hit those armed nmethods after full-gc-pause-end, run nmethod-entry-barrier, and mark them as "hot" (`mark_as_maybe_on_stack`), then in the next full-gc, unloading logic will identify those "hot" nmethods and not unload them. IOW, we use the btw-full-gc window to measure nmethod-temperature.

This has also been my concern when looking at this, however if ZGC/Shenandoah do not care, then (not directed at @albertnetymk , just in general) why should the others?
It would be nice to be uniform here (another random musing), either way is fine. Maybe the ZGC/Shenandoah devs can comment on this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3031206629

From duke at openjdk.org  Thu Jul  3 07:40:56 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 07:40:56 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Move call to print_tracing_info
 - Merge branch 'master' into gc_cpu_time
 - Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time
 - Fixes after @albertnetymk review
 - Change output per discussion
 - Make stop protected, remove integer divison, remove unused method
 - Update closure name
 - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
 - Fixes after review from @stefank
 - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
 - ... and 17 more: https://git.openjdk.org/jdk/compare/c75df634...f9c3aa64

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

Changes: https://git.openjdk.org/jdk/pull/25779/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=16
  Stats: 258 lines in 16 files changed: 244 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From ayang at openjdk.org  Thu Jul  3 08:17:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 08:17:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
Message-ID: <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>

On Thu, 3 Jul 2025 07:40:56 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - Move call to print_tracing_info
>  - Merge branch 'master' into gc_cpu_time
>  - Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time
>  - Fixes after @albertnetymk review
>  - Change output per discussion
>  - Make stop protected, remove integer divison, remove unused method
>  - Update closure name
>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>  - Fixes after review from @stefank
>  - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/c75df634...f9c3aa64

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

> 204: class CPUTimeThreadClosure : public ThreadClosure {
> 205: private:
> 206:   volatile jlong _cpu_time = 0;

There is no need for `volatile`. `gc_threads_do` runs on the calling thread, not on threads we are iterating on.

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

> 224:   if (string_dedup_cpu_time == -1) {
> 225:     return -1;
> 226:   }

Can probably move this to the very beginning for clearer separation: gc-time comes from three sources -- vmthread, string-dedup and gc-threads.

src/hotspot/share/gc/shared/cpuTimeScope.inline.hpp line 57:

> 55:   if (UsePerfData) {
> 56:     CPUTimeCounters::get_instance()->update_counter(CPUTimeGroups::CPUTimeType::vm, end);
> 57:   }

This class (name/interface) seems fairly generic, but the underlying impl is tightly coupled to vmthread. IOW, one can't use this class other than on vmthread. Maybe this class should be inside vmThread.cpp.

src/hotspot/share/runtime/cpuTimeCounters.hpp line 56:

> 54: 
> 55: class CPUTimeCounters: public CHeapObj<mtServiceability> {
> 56:   friend class CPUTimeScope;

I wonder if we avoid this. The public APIs should be enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182127690
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182131415
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182146520
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182156134

From ayang at openjdk.org  Thu Jul  3 08:17:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 08:17:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <o2HJ-mJZUvdhlLJUj2IFJScbBnZC1I6H2lMuGrM3JC0=.4e7ef168-3bb4-486b-a9bb-8fb2602e3985@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
 <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>
 <xXn0o0rIwotlmlz4_Akcte9dFM2-__VOk9XIva7EJ8E=.6f86fecb-a8c6-4b67-abac-958eee215f12@github.com>
 <o2HJ-mJZUvdhlLJUj2IFJScbBnZC1I6H2lMuGrM3JC0=.4e7ef168-3bb4-486b-a9bb-8fb2602e3985@github.com>
Message-ID: <dXW1gV7uqON89fRcIFdANOn1EV5DJlUyHfXLQxaSqgw=.21fc3ddd-4792-48ae-923f-0b960da43226@github.com>

On Thu, 3 Jul 2025 07:13:14 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> I understand the part of splitting it into two methods, but why making it pure-virtual? Wouldn't `{}` as before work?
>
> Both works. I believe it was a stylistic choice.

I see; I'd prefer reverting this, as that reduces the diff size, but up to you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182134255

From duke at openjdk.org  Thu Jul  3 08:50:46 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 08:50:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
 <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
Message-ID: <1byklOUoicnZLix7PmzKBpAWfC_D1vCU22tRRsteank=.844a8042-3546-4e68-ac12-6ad5fb92a0ca@github.com>

On Thu, 3 Jul 2025 08:14:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
>> 
>>  - Move call to print_tracing_info
>>  - Merge branch 'master' into gc_cpu_time
>>  - Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time
>>  - Fixes after @albertnetymk review
>>  - Change output per discussion
>>  - Make stop protected, remove integer divison, remove unused method
>>  - Update closure name
>>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>>  - Fixes after review from @stefank
>>  - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
>>  - ... and 17 more: https://git.openjdk.org/jdk/compare/c75df634...f9c3aa64
>
> src/hotspot/share/runtime/cpuTimeCounters.hpp line 56:
> 
>> 54: 
>> 55: class CPUTimeCounters: public CHeapObj<mtServiceability> {
>> 56:   friend class CPUTimeScope;
> 
> I wonder if we avoid this. The public APIs should be enough.

get_instance() is private. It was not clear to me if we would want to change get_instance() to public

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182226865

From duke at openjdk.org  Thu Jul  3 08:59:49 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 08:59:49 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
 <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
Message-ID: <xaNyGPU0qjjngSwM4JemG_C_KhL3iVihaZjIdcJPLNs=.42dcce70-3ef1-464e-80f0-826855815ee5@github.com>

On Thu, 3 Jul 2025 08:09:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
>> 
>>  - Move call to print_tracing_info
>>  - Merge branch 'master' into gc_cpu_time
>>  - Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time
>>  - Fixes after @albertnetymk review
>>  - Change output per discussion
>>  - Make stop protected, remove integer divison, remove unused method
>>  - Update closure name
>>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>>  - Fixes after review from @stefank
>>  - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
>>  - ... and 17 more: https://git.openjdk.org/jdk/compare/c75df634...f9c3aa64
>
> src/hotspot/share/gc/shared/cpuTimeScope.inline.hpp line 57:
> 
>> 55:   if (UsePerfData) {
>> 56:     CPUTimeCounters::get_instance()->update_counter(CPUTimeGroups::CPUTimeType::vm, end);
>> 57:   }
> 
> This class (name/interface) seems fairly generic, but the underlying impl is tightly coupled to vmthread. IOW, one can't use this class other than on vmthread. Maybe this class should be inside vmThread.cpp.

Good point. I think the class mostly belong in shared/gc so I will rename it to something more specific.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182244772

From duke at openjdk.org  Thu Jul  3 09:06:06 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 09:06:06 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v18]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <Ekyv2ZHZeFh7HQHYHXfwE2gUomcTPzIfyWv7gY7BSFs=.5f8cbf88-0c71-49cc-81ce-1ede650b37e6@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  CPUTimeScope->VMThreadCPUTimeScope, remove volatile and reorder elapsed_gc_cpu_time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/f9c3aa64..5694d6f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=16-17

  Stats: 102 lines in 6 files changed: 47 ins; 46 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From ayang at openjdk.org  Thu Jul  3 10:07:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 10:07:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <1byklOUoicnZLix7PmzKBpAWfC_D1vCU22tRRsteank=.844a8042-3546-4e68-ac12-6ad5fb92a0ca@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
 <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
 <1byklOUoicnZLix7PmzKBpAWfC_D1vCU22tRRsteank=.844a8042-3546-4e68-ac12-6ad5fb92a0ca@github.com>
Message-ID: <pyW7roEt9wrFak4wIM-Si8ygD7DypHU-6osLSYdveXU=.0a4eaeee-5c6a-432d-9f36-bb82dd3d5842@github.com>

On Thu, 3 Jul 2025 08:48:21 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/cpuTimeCounters.hpp line 56:
>> 
>>> 54: 
>>> 55: class CPUTimeCounters: public CHeapObj<mtServiceability> {
>>> 56:   friend class CPUTimeScope;
>> 
>> I wonder if we avoid this. The public APIs should be enough.
>
> get_instance() is private. It was not clear to me if we would want to change get_instance() to public

Why do you need `get_instance`? Can you use the public static API?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182389263

From duke at openjdk.org  Thu Jul  3 10:24:40 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 10:24:40 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v19]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  Remove friend class in CPUTimeCounters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/5694d6f3..c3a7258b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=17-18

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

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

From duke at openjdk.org  Thu Jul  3 10:24:42 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 10:24:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <pyW7roEt9wrFak4wIM-Si8ygD7DypHU-6osLSYdveXU=.0a4eaeee-5c6a-432d-9f36-bb82dd3d5842@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
 <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
 <1byklOUoicnZLix7PmzKBpAWfC_D1vCU22tRRsteank=.844a8042-3546-4e68-ac12-6ad5fb92a0ca@github.com>
 <pyW7roEt9wrFak4wIM-Si8ygD7DypHU-6osLSYdveXU=.0a4eaeee-5c6a-432d-9f36-bb82dd3d5842@github.com>
Message-ID: <froFKd6r4kMesYKiQy_8jPruDyaQgrTRMIhUhmSO9S8=.ae79d6d0-b9ab-4d2f-93bc-0df8641c60c4@github.com>

On Thu, 3 Jul 2025 10:04:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> get_instance() is private. It was not clear to me if we would want to change get_instance() to public
>
> Why do you need `get_instance`? Can you use the public static API?

Oh, now I see what you mean. Thanks for pointing that out :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182420834

From ayang at openjdk.org  Thu Jul  3 10:45:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 10:45:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v19]
In-Reply-To: <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>
Message-ID: <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>

On Thu, 3 Jul 2025 10:24:40 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove friend class in CPUTimeCounters

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

> 463: 
> 464:   double elapsed_gc_cpu_time() const;
> 465:   void log_gc_cpu_time() const;

They can be private, I believe.

src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 109:

> 107: #include "utilities/globalDefinitions.hpp"
> 108: 
> 109: class CollectedHeap;

Should not be necessary given the included header.

src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.hpp line 33:

> 31: #include "utilities/macros.hpp"
> 32: 
> 33: class CollectedHeap;

Should not be necessary given the included header.

src/hotspot/share/gc/shared/vmThreadCpuTimeScope.hpp line 37:

> 35:   bool    _enabled;
> 36:   bool    _is_gc_operation;
> 37:   Thread* _thread;

If this class is solely for vmthread, I guess using the more concrete type `VMThread` here seems more explicit.

src/hotspot/share/runtime/cpuTimeCounters.hpp line 36:

> 34: #include "runtime/perfDataTypes.hpp"
> 35: 
> 36: class VMThreadCPUTimeScope;

Seems unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182436622
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182460139
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182460302
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182449653
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182438065

From duke at openjdk.org  Thu Jul  3 10:52:42 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 10:52:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v19]
In-Reply-To: <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>
 <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>
Message-ID: <sBYMUDKOEzVf94YI-uCl36x4Ib9l8e8yzljyMZB1-5c=.59f08e43-6d95-42ae-ae37-772daba761b5@github.com>

On Thu, 3 Jul 2025 10:29:24 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 friend class in CPUTimeCounters
>
> src/hotspot/share/gc/shared/collectedHeap.hpp line 465:
> 
>> 463: 
>> 464:   double elapsed_gc_cpu_time() const;
>> 465:   void log_gc_cpu_time() const;
> 
> They can be private, I believe.

`elapsed_gc_cpu_time()` will be callable through an MXBean in a future patch I'm planning, but can make `log_gc_cpu_time()` private

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182476362

From duke at openjdk.org  Thu Jul  3 10:58:44 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 10:58:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v19]
In-Reply-To: <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>
 <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>
Message-ID: <ucGVhTMX-S-K1xuy2PSmGFAVywJUMPB_zkO2Bn859KY=.544ef513-4970-4c20-a5fa-c092668b5148@github.com>

On Thu, 3 Jul 2025 10:34:27 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 friend class in CPUTimeCounters
>
> src/hotspot/share/gc/shared/vmThreadCpuTimeScope.hpp line 37:
> 
>> 35:   bool    _enabled;
>> 36:   bool    _is_gc_operation;
>> 37:   Thread* _thread;
> 
> If this class is solely for vmthread, I guess using the more concrete type `VMThread` here seems more explicit.

OK, was storing it as `Thread` as it is only needed for `os::thread_cpu_time`. But now that we have renamed the class to something more specific it makes sense to be more explicit here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182487230

From duke at openjdk.org  Thu Jul  3 11:16:01 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 11:16:01 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v20]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <ftPODMSk4CGkrkszR-0xZQre5EhJHG7aTMwFXcspdmE=.9a4586dc-cf43-45fa-9f9b-e67812180e89@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

 - Remove unnecessary include
 - Remove unnecessary includes, explicit thread type and make log_gc_cpu_time private

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/c3a7258b..a6564c70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=18-19

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

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

From ayang at openjdk.org  Thu Jul  3 11:24:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 11:24:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v20]
In-Reply-To: <ftPODMSk4CGkrkszR-0xZQre5EhJHG7aTMwFXcspdmE=.9a4586dc-cf43-45fa-9f9b-e67812180e89@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ftPODMSk4CGkrkszR-0xZQre5EhJHG7aTMwFXcspdmE=.9a4586dc-cf43-45fa-9f9b-e67812180e89@github.com>
Message-ID: <1gL9vHhimIgmnwZy1Ca-XA9Qk_ykG38m8OpUcn6EC_U=.d782ea80-ec21-4387-b1a5-092c38fe0230@github.com>

On Thu, 3 Jul 2025 11:16:01 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unnecessary include
>  - Remove unnecessary includes, explicit thread type and make log_gc_cpu_time private

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2982789191

From tschatzl at openjdk.org  Thu Jul  3 11:33:43 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 11:33:43 GMT
Subject: RFR: 8361204: Parallel: Skip visiting per-thread nmethods during
 young GC
In-Reply-To: <RIjiddsyzUfQWDTLCMdogWA8YM7ghZbGgkUKaZtABhQ=.75c0938c-bf51-4c79-9076-90a15d5aa7c0@github.com>
References: <RIjiddsyzUfQWDTLCMdogWA8YM7ghZbGgkUKaZtABhQ=.75c0938c-bf51-4c79-9076-90a15d5aa7c0@github.com>
Message-ID: <VINL237gMFhNXaJCFSsGZfsUIn8UylnQpXxAQEFhXm4=.424a47f5-98a9-4bcb-bbae-0924e2fe312c@github.com>

On Wed, 2 Jul 2025 10:01:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Small patch of removing per-thread nmethod visiting during young-gc, because relevant nmethods for young-gc are already tracked by `ScavengableNMethods`.
> 
> Test: tier1-8

lgtm

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26089#pullrequestreview-2982813483

From iwalulya at openjdk.org  Thu Jul  3 11:39:39 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 3 Jul 2025 11:39:39 GMT
Subject: RFR: 8277394: Remove the use of safepoint_workers in reference
 processor
In-Reply-To: <RrtFq3ad8Biz9tWbHwGxvvpbkIBNoYjv9lfmbTeha4I=.869a5cea-cc0e-4205-a396-0519e8d4a277@github.com>
References: <RrtFq3ad8Biz9tWbHwGxvvpbkIBNoYjv9lfmbTeha4I=.869a5cea-cc0e-4205-a396-0519e8d4a277@github.com>
Message-ID: <4-5voxOM4vdAIHZ-KgUU7Ehkijdrh_BA5yHmns4JEXs=.6f426660-6dcb-45e2-928c-8468c64a0de3@github.com>

On Thu, 26 Jun 2025 08:06:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this alternate implementation of 8277394. During the review of the first implementation (https://github.com/openjdk/jdk/pull/6453) the reviews did not like that the `WorkerThreads` were stashed away in the `ReferenceProcessor`.
> 
> This is an alternate implementation that implements the suggestion in the review comments, passing them along through the callers. While this requires a bit more changes, imo it better separates reference processor logic from the execution resources.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

LGTM!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25995#pullrequestreview-2982829952

From tschatzl at openjdk.org  Thu Jul  3 11:46:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 11:46:42 GMT
Subject: RFR: 8277394: Remove the use of safepoint_workers in reference
 processor
In-Reply-To: <4-5voxOM4vdAIHZ-KgUU7Ehkijdrh_BA5yHmns4JEXs=.6f426660-6dcb-45e2-928c-8468c64a0de3@github.com>
References: <RrtFq3ad8Biz9tWbHwGxvvpbkIBNoYjv9lfmbTeha4I=.869a5cea-cc0e-4205-a396-0519e8d4a277@github.com>
 <4-5voxOM4vdAIHZ-KgUU7Ehkijdrh_BA5yHmns4JEXs=.6f426660-6dcb-45e2-928c-8468c64a0de3@github.com>
Message-ID: <CSSG8PNpiKR1xG6169a_RKsIEqaNgiR_98WE09MpHtE=.ec4c7f39-64c0-48c3-a90a-3d789b923da1@github.com>

On Thu, 3 Jul 2025 11:36:44 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this alternate implementation of 8277394. During the review of the first implementation (https://github.com/openjdk/jdk/pull/6453) the reviews did not like that the `WorkerThreads` were stashed away in the `ReferenceProcessor`.
>> 
>> This is an alternate implementation that implements the suggestion in the review comments, passing them along through the callers. While this requires a bit more changes, imo it better separates reference processor logic from the execution resources.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> LGTM!

Thanks @walulyai @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/25995#issuecomment-3031956840

From tschatzl at openjdk.org  Thu Jul  3 11:46:43 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 11:46:43 GMT
Subject: Integrated: 8277394: Remove the use of safepoint_workers in reference
 processor
In-Reply-To: <RrtFq3ad8Biz9tWbHwGxvvpbkIBNoYjv9lfmbTeha4I=.869a5cea-cc0e-4205-a396-0519e8d4a277@github.com>
References: <RrtFq3ad8Biz9tWbHwGxvvpbkIBNoYjv9lfmbTeha4I=.869a5cea-cc0e-4205-a396-0519e8d4a277@github.com>
Message-ID: <fmUirkuPX1Ky6HoowesFANIt8RhVLp58aECk2YXQsvM=.d6b8ec94-68a9-4e3b-8663-992ce36eb798@github.com>

On Thu, 26 Jun 2025 08:06:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this alternate implementation of 8277394. During the review of the first implementation (https://github.com/openjdk/jdk/pull/6453) the reviews did not like that the `WorkerThreads` were stashed away in the `ReferenceProcessor`.
> 
> This is an alternate implementation that implements the suggestion in the review comments, passing them along through the callers. While this requires a bit more changes, imo it better separates reference processor logic from the execution resources.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 5e40fb6b
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e40fb6bda1d56e3eba584b49aa0b68096b34169
Stats:     63 lines in 9 files changed: 18 ins; 26 del; 19 mod

8277394: Remove the use of safepoint_workers in reference processor

Co-authored-by: Albert Mingkun Yang <ayang at openjdk.org>
Reviewed-by: ayang, iwalulya

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

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

From duke at openjdk.org  Thu Jul  3 12:13:59 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 12:13:59 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/a6564c70..54ac0884

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=19-20

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

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

From tschatzl at openjdk.org  Thu Jul  3 12:41:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 12:41:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
Message-ID: <kpDxNYLcuga5RI26xEh0pHPgRfQcUhJK5Yb-WpVXvlg=.16be9a53-de61-4db4-91dd-76a0f9074811@github.com>

On Thu, 3 Jul 2025 12:13:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

lgtm!

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2983009540

From ayang at openjdk.org  Thu Jul  3 13:08:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 13:08:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
Message-ID: <LDVLmUXA2_2WsTY3ebV0IghzL7d6SiavucvQ0FOJEn0=.004dfde6-c0fa-4be1-b779-b5b992ba7338@github.com>

On Thu, 3 Jul 2025 12:13:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

If threads in `elapsed_gc_cpu_time` gets -1 for cpu-time, users wouldn't be notified. Instead, the log will show gc usage is 0%. Could this behavior be surprising? Even worse, if only some threads get `-1`, the final gc usage will look normal but can be off by a noticeable margin.

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2983099464

From duke at openjdk.org  Thu Jul  3 14:02:53 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 14:02:53 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <LDVLmUXA2_2WsTY3ebV0IghzL7d6SiavucvQ0FOJEn0=.004dfde6-c0fa-4be1-b779-b5b992ba7338@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
 <LDVLmUXA2_2WsTY3ebV0IghzL7d6SiavucvQ0FOJEn0=.004dfde6-c0fa-4be1-b779-b5b992ba7338@github.com>
Message-ID: <6tit-z77enFt7qFJzO2zoHMMhH_JV4kt5XXGRrHQ6Ng=.0f2e0a0b-0f1d-47be-8599-1b67d7f469a4@github.com>

On Thu, 3 Jul 2025 13:06:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> If threads in elapsed_gc_cpu_time gets -1 for cpu-time, users wouldn't be notified. Instead, the log will show gc usage is 0%. Could this behavior be surprising? Even worse, if only some threads get -1, the final gc usage will look normal but can be off by a noticeable margin.

If `os::thread_cpu_time` fails only intermittently the numbers may indeed be misleading. However if that ever happens the machine is in a very bad state. Many places in hotspot does not check if it returns -1 at all. Maybe we should consider adding a warning or other type of error handling in `os::thread_cpu_time` but that would belong in another PR imo.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3032390753

From stuefe at openjdk.org  Thu Jul  3 16:57:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 3 Jul 2025 16:57:53 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
Message-ID: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>

`ShenandoahAsserts::print_obj()` does not work for COH if the object is forwarded, since the mark word is overwritten with a forwarding pointer.

Depending on the size of the numerical address of the forwardee, nKlass is either zero or garbage. So we get either an "assert(!is_null(v)) failed: narrow klass value can never be zero", or a SIGSEGV. 

Fix is trivial: don't use obj->klass() directly but get it from ShenandoahForwarding.

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

Commit messages:
 - shenandoahAssertFix

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

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

From ayang at openjdk.org  Fri Jul  4 07:18:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 4 Jul 2025 07:18:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
Message-ID: <0jCq2tboMZs8D5tB0lDRreM0lBPgcpnW5u0919kZewI=.996c1ee1-12ff-4b99-909a-0b30955b32b9@github.com>

On Thu, 3 Jul 2025 12:13:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2985878215

From duke at openjdk.org  Fri Jul  4 07:26:42 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Jul 2025 07:26:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
Message-ID: <mgNFq5DTl1QyT5396-9-VoZcUX6hVfvPsz3LIGN5wi0=.46eb279d-82cd-4cc5-9d48-92d7607097f2@github.com>

On Thu, 3 Jul 2025 12:13:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

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

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3034808361

From duke at openjdk.org  Fri Jul  4 10:19:50 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 4 Jul 2025 10:19:50 GMT
Subject: Integrated: 8359110: Log accumulated GC and process CPU time upon VM
 exit
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <5XnE45PdP7aRtYfKr96jVgSb8fu6im6ZDQIlwNgu6lI=.3af71c8f-4feb-4479-bcd1-2fa5b214ed2c@github.com>

On Thu, 12 Jun 2025 11:28:14 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

This pull request has now been integrated.

Changeset: 56ebb8c1
Author:    Jonas Norlinder <jonas.norlinder at oracle.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56ebb8c1b936e5a4c14486153c9f60df705095ad
Stats:     254 lines in 15 files changed: 240 ins; 9 del; 5 mod

8359110: Log accumulated GC and process CPU time upon VM exit

Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Jonas Norlinder <jnorlinder at openjdk.org>
Reviewed-by: tschatzl, ayang

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

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

From ayang at openjdk.org  Fri Jul  4 11:20:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 4 Jul 2025 11:20:16 GMT
Subject: RFR: 8361404: Parallel: Group all class unloading logc at the end of
 marking phase
Message-ID: <ITJqw3PGoTpqZFWa0_u-Moyk4inPAl1HG-892AYS_5M=.648c95b0-829e-424e-b7ba-77224c739a80@github.com>

Simple patch of moving some out-of-place `ClassLoaderDataGraph` logic to the end of marking-phase in order group all class unloading logic at the same scope/site.

Test: tier1-8

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

Commit messages:
 - pgc-unloading

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

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

From tschatzl at openjdk.org  Fri Jul  4 11:27:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 4 Jul 2025 11:27:44 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v2]
In-Reply-To: <AY5c7vx3q6Tl-MwbAeU7zk1o29zF4ek21kCE4IjZajI=.b81598ed-c6d5-416f-8ab3-f3eb63488b5c@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <AY5c7vx3q6Tl-MwbAeU7zk1o29zF4ek21kCE4IjZajI=.b81598ed-c6d5-416f-8ab3-f3eb63488b5c@github.com>
Message-ID: <n0dgVvvqzTHwyw-5zgv83UMu8RnFa1Bv6XQ4xiOSgeM=.dd2baaa5-9052-485f-aebe-7d281b1a7a96@github.com>

On Mon, 30 Jun 2025 10:30:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor roots processing in Serial (young-gc and full-gc) to clean up the control-flow and make is clearer what roots and closures are used in each context.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

I still do not see that much advantage of the new code over the other but I am not blocking this.

src/hotspot/share/gc/serial/defNewGeneration.cpp line 627:

> 625:     ScavengableNMethods::nmethods_do(&nmethod_cl);
> 626: 
> 627:     OopStorageSet::strong_oops_do(&oop_cl);

Suggestion:

    // During young-gc, visit all (strong+weak) clds with the same closure.
    ClassLoaderDataGraph::cld_do(&cld_cl);

    Threads::oops_do(&oop_cl, &nmethod_cl);

    OopStorageSet::strong_oops_do(&oop_cl);

    ScavengableNMethods::nmethods_do(&nmethod_cl);


Keep same order of CLDG, Thread roots and OopStorage iteration to keep comparability high.

src/hotspot/share/gc/serial/serialFullGC.cpp line 731:

> 729: 
> 730:     NMethodToOopClosure nmthod_cl(&adjust_pointer_closure, NMethodToOopClosure::FixRelocations);
> 731:     CodeCache::nmethods_do(&nmthod_cl);

Suggestion:

    NMethodToOopClosure nmethod_cl(&adjust_pointer_closure, NMethodToOopClosure::FixRelocations);
    CodeCache::nmethods_do(&nmethod_cl);

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

PR Review: https://git.openjdk.org/jdk/pull/26038#pullrequestreview-2986717548
PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2185087687
PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2185084434

From ayang at openjdk.org  Fri Jul  4 12:01:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 4 Jul 2025 12:01:00 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v3]
In-Reply-To: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
Message-ID: <SAyZYkt7EDJDe5SZRM6cLrpYDi1Xog74IyYz5wOvcQU=.3343fbcd-2f09-4af0-8b81-172dd04eb7e4@github.com>

> Refactor roots processing in Serial (young-gc and full-gc) to clean up the control-flow and make is clearer what roots and closures are used in each context.
> 
> Test: tier1-8

Albert Mingkun Yang 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:

 - review
 - Merge branch 'master' into sgc-roots
 - review
 - sgc-roots

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26038/files
  - new: https://git.openjdk.org/jdk/pull/26038/files/0743d5e5..8b779888

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

  Stats: 6323 lines in 255 files changed: 4224 ins; 1221 del; 878 mod
  Patch: https://git.openjdk.org/jdk/pull/26038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26038/head:pull/26038

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

From ayang at openjdk.org  Fri Jul  4 12:01:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 4 Jul 2025 12:01:00 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v2]
In-Reply-To: <n0dgVvvqzTHwyw-5zgv83UMu8RnFa1Bv6XQ4xiOSgeM=.dd2baaa5-9052-485f-aebe-7d281b1a7a96@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <AY5c7vx3q6Tl-MwbAeU7zk1o29zF4ek21kCE4IjZajI=.b81598ed-c6d5-416f-8ab3-f3eb63488b5c@github.com>
 <n0dgVvvqzTHwyw-5zgv83UMu8RnFa1Bv6XQ4xiOSgeM=.dd2baaa5-9052-485f-aebe-7d281b1a7a96@github.com>
Message-ID: <l7WNvs2-TVTj4ScKAJx0aZGCuKnugP0SbyDo8Cnb1bY=.47728586-096b-45d1-82a0-1571208b8f93@github.com>

On Fri, 4 Jul 2025 11:15:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/gc/serial/defNewGeneration.cpp line 627:
> 
>> 625:     ScavengableNMethods::nmethods_do(&nmethod_cl);
>> 626: 
>> 627:     OopStorageSet::strong_oops_do(&oop_cl);
> 
> Suggestion:
> 
>     // During young-gc, visit all (strong+weak) clds with the same closure.
>     ClassLoaderDataGraph::cld_do(&cld_cl);
> 
>     Threads::oops_do(&oop_cl, &nmethod_cl);
> 
>     OopStorageSet::strong_oops_do(&oop_cl);
> 
>     ScavengableNMethods::nmethods_do(&nmethod_cl);
> 
> 
> Keep same order of CLDG, Thread roots and OopStorage iteration to keep comparability high.

It's kind of intentional that `Threads::oops_do(&oop_cl, &nmethod_cl);` and `ScavengableNMethods::nmethods_do(&nmethod_cl);` are next to each other. This way, it becomes more obvious that `Threads::oops_do` don't need to visit nmethod, i.e. nmethod_cl can be null there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2185178116

From iwalulya at openjdk.org  Fri Jul  4 15:28:20 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 4 Jul 2025 15:28:20 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v11]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

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

 - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
 - Albert suggestions
 - Improve comment
 - Thomas Review
 - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
 - Thomas Review
 - Reviews
 - Albert suggestions
 - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
 - remove unrequired changes - kim
 - ... and 1 more: https://git.openjdk.org/jdk/compare/f153e415...5c388d54

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

Changes: https://git.openjdk.org/jdk/pull/25832/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25832&range=10
  Stats: 618 lines in 16 files changed: 395 ins; 89 del; 134 mod
  Patch: https://git.openjdk.org/jdk/pull/25832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25832/head:pull/25832

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

From zgu at openjdk.org  Sun Jul  6 20:17:44 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 6 Jul 2025 20:17:44 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
Message-ID: <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>

On Wed, 18 Jun 2025 09:00:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - version
>  - Merge branch 'master' into pgc-size-policy
>  - revert-aliases
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - merge-fix
>  - merge
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363

src/hotspot/share/gc/parallel/parallelArguments.cpp line 71:

> 69:   // True in product build, since tests using debug build often stress GC
> 70:   if (FLAG_IS_DEFAULT(UseGCOverheadLimit)) {
> 71:     FLAG_SET_DEFAULT(UseGCOverheadLimit, trueInProduct);

Given only Parallel honors `UseGCOverheadLimit`, you may want to set the default to `trueInProduct` in `gc_globals.hpp`

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 381:

> 379:   HeapWord* result = young_gen()->expand_and_allocate(size);
> 380: 
> 381:   if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {

I feel that you changed intent of `should_alloc_in_eden()`. I believe the original intent is to prevent allocating large objects in eden, and here, seems to prevent allocating small objects in old gen.

What benefits do you get?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2160152953
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2160163706

From zgu at openjdk.org  Sun Jul  6 20:17:44 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 6 Jul 2025 20:17:44 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
Message-ID: <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>

On Mon, 19 May 2025 11:05:59 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> The one inside the safepoint will print sth `log_info(gc)("GCOverheadLimitThreshold ...`. There can be multiple concurrent mutators reaching here; printing here is undesirable.
>> 
>> I don't think throwing OOM, from gc's perspective, is an "error".
>
>> I don't think throwing OOM, from gc's perspective, is an "error".
> 
> Nevermind; I just obey the statement in methods `MemAllocator::Allocation::check_out_of_memory` and `Universe::out_of_memory_error_java_heap`.

Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data.

I wonder if you can improve this situtation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2181262727

From zgu at openjdk.org  Sun Jul  6 20:17:46 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 6 Jul 2025 20:17:46 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
Message-ID: <eZpadHAAUfGWXv-sVCeisWIwNA4_WhAMg9lcepI_Q5Q=.40e62fce-378d-4eef-929f-d2338cfe1286@github.com>

On Mon, 30 Jun 2025 10:24:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 898:

> 896:       size_t target_capacity_bytes = total_live_words * HeapWordSize
> 897:                                    + old_space->capacity_in_bytes() * (MarkSweepDeadRatio / 100.0)
> 898:                                    + SpaceAlignment;

Why add `SpaceAlignment`, not `align_up` to `SpaceAlignment`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188503009

From ayang at openjdk.org  Sun Jul  6 21:10:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 6 Jul 2025 21:10:43 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
 <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>
Message-ID: <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>

On Sat, 21 Jun 2025 20:56:37 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - version
>>  - Merge branch 'master' into pgc-size-policy
>>  - revert-aliases
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - merge-fix
>>  - merge
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363
>
> src/hotspot/share/gc/parallel/parallelArguments.cpp line 71:
> 
>> 69:   // True in product build, since tests using debug build often stress GC
>> 70:   if (FLAG_IS_DEFAULT(UseGCOverheadLimit)) {
>> 71:     FLAG_SET_DEFAULT(UseGCOverheadLimit, trueInProduct);
> 
> Given only Parallel honors `UseGCOverheadLimit`, you may want to set the default to `trueInProduct` in `gc_globals.hpp`

It's indeed that only Parallel implements this flag. However, if we decide to change the default value of this flag globally, I feel we should do that in its own PR for better visibility. Currently, this changes the default value only for Parallel, as one expects in a PR titled "Parallel: ...".

> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 381:
> 
>> 379:   HeapWord* result = young_gen()->expand_and_allocate(size);
>> 380: 
>> 381:   if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
> 
> I feel that you changed intent of `should_alloc_in_eden()`. I believe the original intent is to prevent allocating large objects in eden, and here, seems to prevent allocating small objects in old gen.
> 
> What benefits do you get?

I don't see how I changed the semantics.

On baseline, from `mem_allocate_work`:


if (result != nullptr) {
  return result;
}

// If certain conditions hold, try allocating from the old gen.
if (!is_tlab) {
  result = mem_allocate_old_gen(size);
  if (result != nullptr) {
    return result;
  }
}


and


HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) {
  if (!should_alloc_in_eden(size)) {
    // Size is too big for eden.
    return allocate_old_gen_and_record(size);
  }

  return nullptr;
}


The original logic is essentially:


if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
  // allocate in old-gen
}

which is the same as I put here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188594599
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188604946

From ayang at openjdk.org  Sun Jul  6 21:10:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 6 Jul 2025 21:10:43 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
Message-ID: <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>

On Thu, 3 Jul 2025 00:52:56 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>>> I don't think throwing OOM, from gc's perspective, is an "error".
>> 
>> Nevermind; I just obey the statement in methods `MemAllocator::Allocation::check_out_of_memory` and `Universe::out_of_memory_error_java_heap`.
>
> Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data.
> 
> I wonder if you can improve this situtation.

Let me try to rephrase your concern to ensure that I understand you correctly -- after `_gc_overhead_counter >= GCOverheadLimitThreshold`, it's possible that another GC is triggered, which reclaims much free memory, and resets `_gc_overhead_counter` to zero. Then, `HeapDumpOnOutOfMemoryError` will not be able to get the intended heap snapshot.

Is my understanding correct?

(Seems that baseline resets the condition and can encounter the same problem as well.)


        if (limit_exceeded && softrefs_clear) {
          *gc_overhead_limit_was_exceeded = true;
          size_policy()->set_gc_overhead_limit_exceeded(false);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188604729

From ayang at openjdk.org  Sun Jul  6 21:10:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 6 Jul 2025 21:10:45 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <eZpadHAAUfGWXv-sVCeisWIwNA4_WhAMg9lcepI_Q5Q=.40e62fce-378d-4eef-929f-d2338cfe1286@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
 <eZpadHAAUfGWXv-sVCeisWIwNA4_WhAMg9lcepI_Q5Q=.40e62fce-378d-4eef-929f-d2338cfe1286@github.com>
Message-ID: <1OgBWItLa8wkOksSxV6vcWN0Le2Z5uz5dnjIt4EGqak=.802ed747-6662-45fa-86d4-0bc1fb124022@github.com>

On Sun, 6 Jul 2025 18:03:14 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 898:
> 
>> 896:       size_t target_capacity_bytes = total_live_words * HeapWordSize
>> 897:                                    + old_space->capacity_in_bytes() * (MarkSweepDeadRatio / 100.0)
>> 898:                                    + SpaceAlignment;
> 
> Why add `SpaceAlignment`, not `align_up` to `SpaceAlignment`?

The alignment is handled inside the callee. I just wanna leave a minimal delta in the old-gen so that old-gen is not completely full. Otherwise, the next young-gc can not promote anything and will be upgraded to full-gc directly. This is mostly for `UseAdaptiveSizePolicy == false`; if enabled, old-gen will also be resized after full-gc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188611386

From zgu at openjdk.org  Mon Jul  7 00:42:41 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 00:42:41 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
 <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
Message-ID: <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>

On Sun, 6 Jul 2025 20:59:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data.
>> 
>> I wonder if you can improve this situtation.
>
> Let me try to rephrase your concern to ensure that I understand you correctly -- after `_gc_overhead_counter >= GCOverheadLimitThreshold`, it's possible that another GC is triggered, which reclaims much free memory, and resets `_gc_overhead_counter` to zero. Then, `HeapDumpOnOutOfMemoryError` will not be able to get the intended heap snapshot.
> 
> Is my understanding correct?
> 
> (Seems that baseline resets the condition and can encounter the same problem as well.)
> 
> 
>         if (limit_exceeded && softrefs_clear) {
>           *gc_overhead_limit_was_exceeded = true;
>           size_policy()->set_gc_overhead_limit_exceeded(false);

Yes. I don't think it is exceeding overhead limit only problem, but OOM and heap dump have to be, in a sense of `atomic`. We encountered  this problem in real production system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188761699

From zgu at openjdk.org  Mon Jul  7 00:42:41 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 00:42:41 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
 <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>
 <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>
Message-ID: <eVepnCg32apDKXAn7rezipT5YRqLa8c-cjjARftsnoQ=.e90c58d3-ba06-41c1-9cd5-94ba49e322a2@github.com>

On Sun, 6 Jul 2025 21:00:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 381:
>> 
>>> 379:   HeapWord* result = young_gen()->expand_and_allocate(size);
>>> 380: 
>>> 381:   if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
>> 
>> I feel that you changed intent of `should_alloc_in_eden()`. I believe the original intent is to prevent allocating large objects in eden, and here, seems to prevent allocating small objects in old gen.
>> 
>> What benefits do you get?
>
> I don't see how I changed the semantics.
> 
> On baseline, from `mem_allocate_work`:
> 
> 
> if (result != nullptr) {
>   return result;
> }
> 
> // If certain conditions hold, try allocating from the old gen.
> if (!is_tlab) {
>   result = mem_allocate_old_gen(size);
>   if (result != nullptr) {
>     return result;
>   }
> }
> 
> 
> and
> 
> 
> HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) {
>   if (!should_alloc_in_eden(size)) {
>     // Size is too big for eden.
>     return allocate_old_gen_and_record(size);
>   }
> 
>   return nullptr;
> }
> 
> 
> The original logic is essentially:
> 
> 
> if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
>   // allocate in old-gen
> }
> 
> which is the same as I put here.

Ah, okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188761974

From zgu at openjdk.org  Mon Jul  7 00:47:43 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 00:47:43 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <1OgBWItLa8wkOksSxV6vcWN0Le2Z5uz5dnjIt4EGqak=.802ed747-6662-45fa-86d4-0bc1fb124022@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
 <eZpadHAAUfGWXv-sVCeisWIwNA4_WhAMg9lcepI_Q5Q=.40e62fce-378d-4eef-929f-d2338cfe1286@github.com>
 <1OgBWItLa8wkOksSxV6vcWN0Le2Z5uz5dnjIt4EGqak=.802ed747-6662-45fa-86d4-0bc1fb124022@github.com>
Message-ID: <--1bClROkHGNgp0ZOioqohKNJU41qoL_k66W285wP70=.298c6a26-9f05-401e-96d6-afa2dacc1356@github.com>

On Sun, 6 Jul 2025 21:07:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 898:
>> 
>>> 896:       size_t target_capacity_bytes = total_live_words * HeapWordSize
>>> 897:                                    + old_space->capacity_in_bytes() * (MarkSweepDeadRatio / 100.0)
>>> 898:                                    + SpaceAlignment;
>> 
>> Why add `SpaceAlignment`, not `align_up` to `SpaceAlignment`?
>
> The alignment is handled inside the callee. I just wanna leave a minimal delta in the old-gen so that old-gen is not completely full. Otherwise, the next young-gc can not promote anything and will be upgraded to full-gc directly. This is mostly for `UseAdaptiveSizePolicy == false`; if enabled, old-gen will also be resized after full-gc.

After [JDK-8328744](https://bugs.openjdk.org/browse/JDK-8328744),  it no longer uses old-gen capacity, but max old-gen size to estimate if promotion can succeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188764546

From duke at openjdk.org  Mon Jul  7 03:02:55 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 7 Jul 2025 03:02:55 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v3]
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <6iybzjYUy4NEsceMFvm68jnstlojWf9L3ckRrYvohI0=.95f04354-722d-4751-9a2a-7d21ad7f981f@github.com>

> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
> 
> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
> 
> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.

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

  Remove unnecessary soft_max_capacity accesses

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25943/files
  - new: https://git.openjdk.org/jdk/pull/25943/files/49bda04e..00034259

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

  Stats: 64 lines in 16 files changed: 4 ins; 32 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/25943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25943/head:pull/25943

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

From duke at openjdk.org  Mon Jul  7 03:11:40 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 7 Jul 2025 03:11:40 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v2]
In-Reply-To: <0-_c2MpqhmXuv_rN3VHirKNVbqLn6Y-xEPk2Czj68GY=.af55e164-7565-4a7e-ab89-ffbb989b1401@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <o1wfwjjIJEcEOxI7ZNeNapByyhJsEBi22iu2nDNm3Lw=.954ab02a-5582-4474-ae82-d9a64fa41123@github.com>
 <-6IGc4gDm8t7AEFTtRbpGXLvVXvsKm9QWGfLGaGU2ls=.8c897937-ab45-45f9-bb5d-9ec54fd99563@github.com>
 <0-_c2MpqhmXuv_rN3VHirKNVbqLn6Y-xEPk2Czj68GY=.af55e164-7565-4a7e-ab89-ffbb989b1401@github.com>
Message-ID: <AKT_rfw0fZThyYroK3Zl1dwAMOmX8Ea-UuNJ6WGychY=.94270c28-9953-45ee-8420-34bae32dd7a5@github.com>

On Mon, 30 Jun 2025 23:02:23 GMT, Rui Li <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 1017:
>> 
>>> 1015: size_t ShenandoahGeneration::soft_max_capacity() const {
>>> 1016:   size_t capacity = ShenandoahGenerationalHeap::heap()->soft_max_capacity();
>>> 1017:   log_debug(gc)("soft_max_capacity: %zu", capacity); // TestDynamicSoftMaxHeapSize needs the log line to validate
>> 
>> This will be a hot method. It's called by the heuristic frequently to test if it should start a GC. We may also even test this on the allocation path. I'd rather not have a log level check here just for one test case. Can we move this log message to the place where the value is updated? I expect the value to change _much less_ frequently than it is read.
>
> Agree that the debug log can be too much in the log and impact perf. There is an existing log when soft max is changed: [link](https://github.com/openjdk/jdk/blob/6df0f5e390ecf874c1eca7284c51efa65ce23737/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L865-L868). The problem is, before the fix, when the soft max was changed, gen shen  doesn't read the changed value. That's why I put a log here. Validating log is also indeed a bit fragile. If we remove the log, probably need to think another way to test.
> 
> 
> For removing `soft_max_capacity`: not sure if I understand it right, but I thought `ShenandoahSpaceInfo` was the parent class in the polymorphism ([code](https://github.com/openjdk/jdk/blob/6df0f5e390ecf874c1eca7284c51efa65ce23737/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp#L68)), so the code would work for both gen shen (ShenandoahGeneration) and ShenandoahGlobalGeneration? If we removed `soft_max_capacity ` from ShenandoahSpaceInfo, wouldn't that make heuristics not able to access soft max heap size?

Realized just simply replace `_space_info->soft_max_capacity()` with `ShenandoahHeap::heap()->soft_max_capacity()`. 

Updated in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2188877998

From duke at openjdk.org  Mon Jul  7 03:38:12 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 7 Jul 2025 03:38:12 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v4]
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <bpHp-0C2cifPXbK1ibfTwb_CvNUFQjj22Qm0W52Bj5U=.c995fe10-ef26-4f81-881f-354afc92cd1b@github.com>

> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
> 
> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
> 
> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.

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

  Remove extra arg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25943/files
  - new: https://git.openjdk.org/jdk/pull/25943/files/00034259..503e83ec

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

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

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

From ayang at openjdk.org  Mon Jul  7 07:57:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 7 Jul 2025 07:57:32 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v20]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - review
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - cast
 - remove-young-resize-after-full-gc
 - Merge branch 'master' into pgc-size-policy
 - ... and 20 more: https://git.openjdk.org/jdk/compare/d75ea7e6...2e8e19db

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=19
  Stats: 4361 lines in 31 files changed: 505 ins; 3470 del; 386 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From ayang at openjdk.org  Mon Jul  7 07:57:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 7 Jul 2025 07:57:33 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
 <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
 <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>
Message-ID: <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com>

On Mon, 7 Jul 2025 00:39:20 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> but OOM and heap dump have to be, in a sense of atomic

I see; it can indeed be annoying that heap-dump doesn't capture the intended snapshot -- a java thread can trigger a gc that changes heap-content. However, AFAICS, fixing that non-atomic issue requires updating callers of `report_java_out_of_memory`. Therefore, I am inclined to think it should be addressed in its own ticket. It's a preexisting issue on master as well, not sth newly introduced by this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2189268507

From ayang at openjdk.org  Mon Jul  7 08:02:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 7 Jul 2025 08:02:42 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
 <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
 <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>
 <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com>
Message-ID: <tSmjzdgYHVLvtLde3VTSTYmUPf9fUZfbJMFrNKfaBW0=.a6b46172-e442-48c1-a3e9-39751ad600f5@github.com>

On Mon, 7 Jul 2025 07:53:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Yes. I don't think it is exceeding overhead limit only problem, but OOM and heap dump have to be, in a sense of `atomic`. We encountered  this problem in real production system.
>
>> but OOM and heap dump have to be, in a sense of atomic
> 
> I see; it can indeed be annoying that heap-dump doesn't capture the intended snapshot -- a java thread can trigger a gc that changes heap-content. However, AFAICS, fixing that non-atomic issue requires updating callers of `report_java_out_of_memory`. Therefore, I am inclined to think it should be addressed in its own ticket. It's a preexisting issue on master as well, not sth newly introduced by this PR.

Does https://bugs.openjdk.org/browse/JDK-8347833 match the problem you have in mind?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2189284517

From gli at openjdk.org  Mon Jul  7 10:02:05 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 7 Jul 2025 10:02:05 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v20]
In-Reply-To: <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>
Message-ID: <rUfbOFKXnmhEtvfydubkdKWLMTYMa5n-PP7HgBRTlaY=.48ed6ee5-6b44-4485-a0e0-7a993002eaa0@github.com>

On Mon, 7 Jul 2025 07:57:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - cast
>  - remove-young-resize-after-full-gc
>  - Merge branch 'master' into pgc-size-policy
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/d75ea7e6...2e8e19db

Marked as reviewed by gli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2993059953

From tschatzl at openjdk.org  Mon Jul  7 12:36:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Jul 2025 12:36:40 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - * indentation fix
 - ... and 47 more: https://git.openjdk.org/jdk/compare/d75ea7e6...441c234a

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=40
  Stats: 7121 lines in 112 files changed: 2585 ins; 3590 del; 946 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

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

From zgu at openjdk.org  Mon Jul  7 13:32:56 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 13:32:56 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v20]
In-Reply-To: <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>
Message-ID: <zPyY-uHKb2yN-6a7_mwPEMnpniVJ-T-AqgtIUqvXJQ0=.3312829e-7868-47a8-b641-3ccba94247ab@github.com>

On Mon, 7 Jul 2025 07:57:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - cast
>  - remove-young-resize-after-full-gc
>  - Merge branch 'master' into pgc-size-policy
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/d75ea7e6...2e8e19db

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2993906888

From zgu at openjdk.org  Mon Jul  7 13:32:58 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 13:32:58 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
 <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>
 <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>
Message-ID: <YS4qYlS4Wg7wr8_vq0SNb4S--mFBFPDh3OI7T8nnaqo=.f4037a89-ec38-451b-9f8e-766fee8fc270@github.com>

On Sun, 6 Jul 2025 20:47:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelArguments.cpp line 71:
>> 
>>> 69:   // True in product build, since tests using debug build often stress GC
>>> 70:   if (FLAG_IS_DEFAULT(UseGCOverheadLimit)) {
>>> 71:     FLAG_SET_DEFAULT(UseGCOverheadLimit, trueInProduct);
>> 
>> Given only Parallel honors `UseGCOverheadLimit`, you may want to set the default to `trueInProduct` in `gc_globals.hpp`
>
> It's indeed that only Parallel implements this flag. However, if we decide to change the default value of this flag globally, I feel we should do that in its own PR for better visibility. Currently, this changes the default value only for Parallel, as one expects in a PR titled "Parallel: ...".

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2190120397

From zgu at openjdk.org  Mon Jul  7 13:32:59 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 13:32:59 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <tSmjzdgYHVLvtLde3VTSTYmUPf9fUZfbJMFrNKfaBW0=.a6b46172-e442-48c1-a3e9-39751ad600f5@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
 <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
 <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>
 <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com>
 <tSmjzdgYHVLvtLde3VTSTYmUPf9fUZfbJMF
 rNKfaBW0=.a6b46172-e442-48c1-a3e9-39751ad600f5@github.com>
Message-ID: <kor33oeaR3oZDaBU7gU14WHcN_lGL3hbXsZBk1pY4JA=.f68f0632-95f0-4bba-a36c-f24ab3be9476@github.com>

On Mon, 7 Jul 2025 07:59:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> but OOM and heap dump have to be, in a sense of atomic
>> 
>> I see; it can indeed be annoying that heap-dump doesn't capture the intended snapshot -- a java thread can trigger a gc that changes heap-content. However, AFAICS, fixing that non-atomic issue requires updating callers of `report_java_out_of_memory`. Therefore, I am inclined to think it should be addressed in its own ticket. It's a preexisting issue on master as well, not sth newly introduced by this PR.
>
> Does https://bugs.openjdk.org/browse/JDK-8347833 match the problem you have in mind?

Yes. Sounds good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2190117730

From tschatzl at openjdk.org  Mon Jul  7 13:36:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Jul 2025 13:36:53 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info()
Message-ID: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>

Hi all,

  please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.

The change moves these methods to `protected` visibility.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8361349

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

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

From ayang at openjdk.org  Mon Jul  7 14:04:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 7 Jul 2025 14:04:42 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info()
In-Reply-To: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
Message-ID: <c_fGFeNrF5ysBpWriB_1eA7IoLpvMTCBIApTGpkMKno=.8a22f725-c1af-4296-9913-a1f7d387ac58@github.com>

On Mon, 7 Jul 2025 13:30:44 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.
> 
> The change moves these methods to `protected` visibility.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26160#pullrequestreview-2994041889