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

From tschatzl at openjdk.org  Mon Jul  7 16:21:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Jul 2025 16:21:57 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v2]
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: <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@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

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

  * iwalulya suggested to make leaf classes use private; although probably one wants to use final, but Hotspot does not seem to use that

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26160/files
  - new: https://git.openjdk.org/jdk/pull/26160/files/d601eb4d..5fd5d6f7

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

  Stats: 6 lines in 6 files changed: 0 ins; 5 del; 1 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 iwalulya at openjdk.org  Mon Jul  7 16:36:39 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 7 Jul 2025 16:36:39 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v2]
In-Reply-To: <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
 <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@github.com>
Message-ID: <KVlt3wrUbyp2rSUB2PWsOZFPdDoVmI30587-wjKfMzQ=.d667c698-e467-45a4-9cdf-00d23c740f5a@github.com>

On Mon, 7 Jul 2025 16:21:57 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
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * iwalulya suggested to make leaf classes use private; although probably one wants to use final, but Hotspot does not seem to use that

Nit:

src/hotspot/share/gc/epsilon/epsilonHeap.hpp line 52:

> 50:   volatile size_t _last_heap_print;
> 51: 
> 52: private:

private: can be removed.

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26160#pullrequestreview-2994627357
PR Review Comment: https://git.openjdk.org/jdk/pull/26160#discussion_r2190587513

From tschatzl at openjdk.org  Mon Jul  7 18:57:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Jul 2025 18:57:41 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <tbgVTlCFP93HyQ5PvIJyGAT9dY8qoJ8Jw3gcygYF7dI=.e3de1896-e3db-466d-a420-79b602917a66@github.com>
References: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
 <tbgVTlCFP93HyQ5PvIJyGAT9dY8qoJ8Jw3gcygYF7dI=.e3de1896-e3db-466d-a420-79b602917a66@github.com>
Message-ID: <Jvyx8hvQjO42_3lhqsOuWEnP61La2ZMPsA1Z8phqdDY=.55223f0b-4c89-40f7-9199-342c144b7c63@github.com>

On Tue, 24 Jun 2025 08:52:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> >   
> > However, the current logic that a young-gc can cancel a full-gc (`_codecache_GC_aggressive` in this case) also seems surprising.
> 
> That's a different issue.

Actually most likely this is the issue for Parallel GC; that code is present only in older JDK versions before 25 (however other reasons like the `GCLocker` may also prevent these GCs), i.e. there should be no such issue in JDK 25 for Parallel GC.

The situation for Parallel GC is different for earlier versions, i.e. for backporting: it would require the changes for [??JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647) and at least one other fix. There needs to be a cost/benefit analysis these are rather intrusive changes.

@ajacob:

> I considered a few different options before making this change:
>
>  1.  Always call Universe::heap()->collect(...) without making any check (the GC impl should handle the situation)
>  2.  Fix all GCs implementation to ensure _unloading_threshold_gc_requested gets back to false at some point (probably what is supposed to happen today)
>  3.  Change CollectedHeap::collect to return a bool instead of void to indicate if GC was run or scheduled

I had a spin at the (imo correct) fix for 2 - fix G1 `collect()` logic.

Here's a diff: https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:submit/8350621-code-cache-mgmt-hang?expand=1

What do you think?

Thanks,
  Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/23656#issuecomment-3035131232

From duke at openjdk.org  Mon Jul  7 18:57:42 2025
From: duke at openjdk.org (Alexandre Jacob)
Date: Mon, 7 Jul 2025 18:57:42 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
References: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
Message-ID: <qhuUzfr7r40iPqMkS_MeKmBmOvH9CW2oxIP-xA9vDOE=.c1c31bc7-ab44-4f97-a5ac-7e8316b16544@github.com>

On Sun, 16 Feb 2025 18:39:29 GMT, Alexandre Jacob <duke at openjdk.org> wrote:

> The purpose of this PR is to fix a bug where we can end up in a situation where the GC is not scheduled anymore by `CodeCache`.
> 
> This situation is possible because the `_unloading_threshold_gc_requested` flag is set to `true` when triggering the GC and we expect the GC to call `CodeCache::on_gc_marking_cycle_finish` which in turn will call `CodeCache::update_cold_gc_count`, which will reset the flag `_unloading_threshold_gc_requested` allowing further GC scheduling.
> 
> Unfortunately this can't work properly under certain circumstances.
> For example, if using G1GC, calling `G1CollectedHeap::collect` does no give the guarantee that the GC will actually run as it can be already running (see [here](https://github.com/openjdk/jdk/blob/7d11418c820b46926a25907766d16083a4b349de/src/hotspot/share/gc/g1/g1CollectedHeap.cpp#L1763)).
> 
> I have observed this behavior on JVM in version 21 that were migrated recently from java 17.
> Those JVMs have some pressure on code cache and quite a large heap in comparison to allocation rate, which means that objects are mostly GC'd by young collections and full GC take a long time to happen.
> 
> I have been able to reproduce this issue with ParallelGC and G1GC, and I imagine that other GC can be impacted as well.
> 
> In order to reproduce this issue, I found a very simple and convenient way:
> 
> 
> public class CodeCacheMain {
>     public static void main(String[] args) throws InterruptedException {
>         while (true) {
>             Thread.sleep(100);
>         }
>     }
> }
> 
> 
> Run this simple app with the following JVM flags:
> 
> 
> -Xlog:gc*=info,codecache=info -Xmx512m -XX:ReservedCodeCacheSize=2496k -XX:StartAggressiveSweepingAt=15
> 
> 
> - 512m for the heap just to clarify the intent that we don't want to be bothered by a full GC
> - low `ReservedCodeCacheSize` to put pressure on code cache quickly
> - `StartAggressiveSweepingAt` can be set to 20 or 15 for faster bug reproduction
> 
> Itself, the program will hardly get pressure on code cache, but the good news is that it is sufficient to attach a jconsole on it which will:
> - allows us to monitor code cache
> - indirectly generate activity on the code cache, just what we need to reproduce the bug
> 
> Some logs related to code cache will show up at some point with GC activity:
> 
> 
> [648.733s][info][codecache      ] Triggering aggressive GC due to having only 14.970% free memory
> 
> 
> And then it will stop and we'll end up with the following message:
> 
> 
> [672.714s][info][codecache      ] Code cache is full - disabling compilation
> 
> 
> L...

Hello, I'm sorry I didn't get back to you sooner on this PR.

Indeed I considered the first option (do not try to prevent calls to `Universe::heap()->collect(...)`) but wanted to have something more elaborated instead.

@tschatzl I like your proposal of fixing the GC implementation directly, as mentioned in my PR description it was my favorite option but because I found that this bug existed for at least Parallel GC and G1 I wanted to have something in CodeCache directly to ensure we never have an issue related to GC implementation.
I had a look at your commit and feel like it is the good direction for G1. Thank you for having a look at it

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

PR Comment: https://git.openjdk.org/jdk/pull/23656#issuecomment-3046216533

From duke at openjdk.org  Mon Jul  7 19:16:39 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Mon, 7 Jul 2025 19:16:39 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v2]
In-Reply-To: <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
 <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@github.com>
Message-ID: <w9mMA1CVOfPC9GBDVWjePr7Cr1zmeQ69Yy6H_DAYVYU=.fac7caca-2aaa-4921-ad41-006144704588@github.com>

On Mon, 7 Jul 2025 16:21:57 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
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * iwalulya suggested to make leaf classes use private; although probably one wants to use final, but Hotspot does not seem to use that

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

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

From kbarrett at openjdk.org  Mon Jul  7 22:04:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 7 Jul 2025 22:04:42 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v11]
In-Reply-To: <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>
Message-ID: <ov6uqZnAEu8_sdMRzViK177VtAO5LI5Ow1qQSYxQNak=.f8b5aebf-f979-44af-8243-e837a129ee41@github.com>

On Fri, 4 Jul 2025 15:28:20 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 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

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25832#pullrequestreview-2995359702

From kbarrett at openjdk.org  Mon Jul  7 22:04:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 7 Jul 2025 22:04:43 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v11]
In-Reply-To: <9m4YNoOw_rp9t4ohninQDMbzc_-18rZBVQNvxMQCFSM=.c624e95c-39bf-4693-9331-a7a1f5d44484@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>
 <9m4YNoOw_rp9t4ohninQDMbzc_-18rZBVQNvxMQCFSM=.c624e95c-39bf-4693-9331-a7a1f5d44484@github.com>
Message-ID: <DL5H3nrb0SiymYDR45Tjj8oH0cofkmGkJBDOQ5sHmQk=.d4ba763e-b99e-42f6-af5a-f31f624d15d8@github.com>

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

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

Oh, right you are!

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

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

From duke at openjdk.org  Tue Jul  8 00:23:55 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 00:23:55 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v5]
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@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:

  Use comment style

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

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

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

  Stats: 160 lines in 1 file changed: 97 ins; 49 del; 14 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 tschatzl at openjdk.org  Tue Jul  8 07:50:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Jul 2025 07:50:45 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <qhuUzfr7r40iPqMkS_MeKmBmOvH9CW2oxIP-xA9vDOE=.c1c31bc7-ab44-4f97-a5ac-7e8316b16544@github.com>
References: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
 <qhuUzfr7r40iPqMkS_MeKmBmOvH9CW2oxIP-xA9vDOE=.c1c31bc7-ab44-4f97-a5ac-7e8316b16544@github.com>
Message-ID: <jbMyHIEGHB8t04t61Wa452ybkb0GEZj3SwIXiO1IadI=.21bb7266-6282-4fe4-b78c-9b5e6a7cdebd@github.com>

On Mon, 7 Jul 2025 18:54:55 GMT, Alexandre Jacob <duke at openjdk.org> wrote:

> Hello, I'm sorry I didn't get back to you sooner on this PR.
> 

No worries, it should be rather me to not get to this earlier....

> Indeed I considered the first option (do not try to prevent calls to `Universe::heap()->collect(...)`) but wanted to have something more elaborated instead.
> 
> @tschatzl I like your proposal of fixing the GC implementation directly, as mentioned in my PR description it was my favorite option but because I found that this bug existed for at least Parallel GC and G1 I wanted to have something in CodeCache directly to ensure we never have an issue related to GC implementation. I had a look at your commit and feel like it is the good direction for G1. Thank you for having a look at it

First, I assume you verified my change ;)

How do we proceed from here? Do you want to reuse this PR or should we (I, you?) open a new one for the new suggestion?

What do you prefer? I am fine with either option.

Thanks,
  Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/23656#issuecomment-3047757426

From stuefe at openjdk.org  Tue Jul  8 08:28:44 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Jul 2025 08:28:44 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <MTpr4gfUVI80umJYXUVQ9kyE_mLcWpHqmV6B-u7WrUs=.ecb714ac-4acb-4ced-a40a-4b19a4d9604a@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `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 non-null bits of the forwardee (whether it spills into the nKlass bits), 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.

Ping @shipilev, maybe? Or @rkennke? Its really trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/26117#issuecomment-3047877896

From tschatzl at openjdk.org  Tue Jul  8 08:29:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Jul 2025 08:29:42 GMT
Subject: RFR: 8361404: Parallel: Group all class unloading logc at the end
 of marking phase
In-Reply-To: <ITJqw3PGoTpqZFWa0_u-Moyk4inPAl1HG-892AYS_5M=.648c95b0-829e-424e-b7ba-77224c739a80@github.com>
References: <ITJqw3PGoTpqZFWa0_u-Moyk4inPAl1HG-892AYS_5M=.648c95b0-829e-424e-b7ba-77224c739a80@github.com>
Message-ID: <LyzGl0hqwSYQ-eUtcXrhq0IPppG-z2w-O92uJxxD4-8=.c397f98d-8c49-4b25-86d7-a119e647d7b2@github.com>

On Fri, 4 Jul 2025 11:15:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 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

lgtm. Do not know why I did the original change that way... :(

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26130#pullrequestreview-2996537767

From tschatzl at openjdk.org  Tue Jul  8 08:30:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Jul 2025 08:30:40 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v2]
In-Reply-To: <l7WNvs2-TVTj4ScKAJx0aZGCuKnugP0SbyDo8Cnb1bY=.47728586-096b-45d1-82a0-1571208b8f93@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>
 <l7WNvs2-TVTj4ScKAJx0aZGCuKnugP0SbyDo8Cnb1bY=.47728586-096b-45d1-82a0-1571208b8f93@github.com>
Message-ID: <aXCllVQNeMyLlh80qB78hpDvAOV-QmK1V9ekY11YX1s=.8e8b7d49-ef78-48d0-b421-bc5721620d34@github.com>

On Fri, 4 Jul 2025 11:58:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

The most obvious thing to me would be explicitly spelling it out instead of assuming some reader's intuition, but I see your point.

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

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

From tschatzl at openjdk.org  Tue Jul  8 08:32:18 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Jul 2025 08:32:18 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v3]
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: <IatqrJG2oDgzOXFu8TQQpFKwefD2P3qGZvaMCKX4tYs=.52545b7a-4557-40b3-81b8-058dbc2a202d@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

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

  * remove one more unnecessary `private`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26160/files
  - new: https://git.openjdk.org/jdk/pull/26160/files/5fd5d6f7..087d72b7

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

  Stats: 1 line in 1 file changed: 0 ins; 1 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 iwalulya at openjdk.org  Tue Jul  8 08:32:18 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 8 Jul 2025 08:32:18 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v3]
In-Reply-To: <IatqrJG2oDgzOXFu8TQQpFKwefD2P3qGZvaMCKX4tYs=.52545b7a-4557-40b3-81b8-058dbc2a202d@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
 <IatqrJG2oDgzOXFu8TQQpFKwefD2P3qGZvaMCKX4tYs=.52545b7a-4557-40b3-81b8-058dbc2a202d@github.com>
Message-ID: <1I--DXjCGgzHqtiKzm0OxjTMtURCvO7YFZjjU4iZo_8=.09a6b6ac-dade-4c6a-8a94-c7ce79590dda@github.com>

On Tue, 8 Jul 2025 08:29:21 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
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove one more unnecessary `private`

LGTM!

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

Marked as reviewed by iwalulya (Reviewer).

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

From rkennke at openjdk.org  Tue Jul  8 08:51:47 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Jul 2025 08:51:47 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <0tqh-ywEfDa4TN2ihTO5xxgNmpAv1EcJMSJBbzcbBEc=.3f0dffb4-37fc-49c0-a0fa-7e54214e8aec@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `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 non-null bits of the forwardee (whether it spills into the nKlass bits), 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.

Good! Thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26117#pullrequestreview-2996617172

From shade at openjdk.org  Tue Jul  8 08:56:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 08:56:42 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <ElNQ62y7sHz9RwBdZHtOynC5is9gEfVa7noNClraqCw=.0da72e27-beeb-49ac-9592-6a8892e3d8dc@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `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 non-null bits of the forwardee (whether it spills into the nKlass bits), 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.

There are two peculiarities in this method. It is normally called from diagnostics code, and so we are not 100% sure it it is even safe to reach through the fwdptr for klass. Second, we should be printing the raw header at least in some cases, because again, diagnostics.

Let me think about it...

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

PR Review: https://git.openjdk.org/jdk/pull/26117#pullrequestreview-2996640881

From shade at openjdk.org  Tue Jul  8 09:37:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 09:37:49 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks
Message-ID: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>

Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):

First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs

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

Commit messages:
 - Fix

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

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

From shade at openjdk.org  Tue Jul  8 09:37:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 09:37:50 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks
In-Reply-To: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
Message-ID: <7NiYQfhdKfEjiTXwZ_Y9tuCb6Hub7CMrfAVfTNLMUwY=.83cfd9f3-b1da-4600-b22a-dc15b1378d8b@github.com>

On Tue, 8 Jul 2025 09:02:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
> 
> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs

Both benchmark scores and the errors improve. So we made the test more accurate and more precise at the same time.


Benchmark                       Mode  Cnt    Score   Error  Units

# Mainline
AllDead.gc                        ss   25    9.439 ? 0.117  ms/op
AllLive.gc                        ss   25   17.979 ? 0.126  ms/op
DifferentObjectSizesArray.gc      ss   25   72.549 ? 0.363  ms/op
DifferentObjectSizesHashMap.gc    ss   25   75.390 ? 0.336  ms/op
DifferentObjectSizesTreeMap.gc    ss   25   86.146 ? 1.813  ms/op
HalfDeadFirstPart.gc              ss   25   13.558 ? 0.127  ms/op
HalfDeadInterleaved.gc            ss   25   64.643 ? 0.347  ms/op
HalfDeadInterleavedChunks.gc      ss   25   59.416 ? 0.218  ms/op
HalfDeadSecondPart.gc             ss   25   13.405 ? 0.150  ms/op
HalfHashedHalfDead.gc             ss   25   68.121 ? 0.328  ms/op
NoObjects.gc                      ss   25    7.879 ? 0.099  ms/op
OneBigObject.gc                   ss   25  118.887 ? 0.697  ms/op

# This PR
AllDead.gc                        ss  125    7.352 ? 0.060  ms/op
AllLive.gc                        ss  125   14.964 ? 0.069  ms/op
DifferentObjectSizesArray.gc      ss  125   70.373 ? 0.125  ms/op
DifferentObjectSizesHashMap.gc    ss  125   73.404 ? 0.137  ms/op
DifferentObjectSizesTreeMap.gc    ss  125   81.512 ? 1.044  ms/op
HalfDeadFirstPart.gc              ss  125   10.806 ? 0.047  ms/op
HalfDeadInterleaved.gc            ss  125   61.393 ? 0.097  ms/op
HalfDeadInterleavedChunks.gc      ss  125   56.400 ? 0.094  ms/op
HalfDeadSecondPart.gc             ss  125   10.748 ? 0.056  ms/op
HalfHashedHalfDead.gc             ss  125   64.909 ? 0.091  ms/op
NoObjects.gc                      ss  125    5.616 ? 0.063  ms/op
OneBigObject.gc                   ss  125  116.459 ? 0.324  ms/op


The drawback is that we do more work, so run times and cpu consumption is about 2..3x worse. That's the price we pay for more precision/accuracy.


# Mainline
real	5m46.048s
user	9m42.887s
sys	37m20.507s

# This PR
real	12m3.271s
user	67m55.798s
sys	34m46.397s

In the [JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960), where I was chasing a regression, we now in much better place, focusing on more stable GC cost.


# java -jar benchmarks.jar AllDead.gc --jvmArgsAppend "-XX:+UseZGC"
Mainline: 80,596 ? 3,801  ms/op
This PR:   6,057 ? 0,097  ms/op

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

PR Comment: https://git.openjdk.org/jdk/pull/26182#issuecomment-3048014191
PR Comment: https://git.openjdk.org/jdk/pull/26182#issuecomment-3048112617

From shade at openjdk.org  Tue Jul  8 10:13:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 10:13:17 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v2]
In-Reply-To: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
Message-ID: <s87mCiPyGQdFOI5jyUA5xlh5CXoAQsGkMlRvNiEMk0k=.3eabc110-d856-461e-9328-8f520491f8b8@github.com>

> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
> 
> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs

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

  Revert accidental comment removal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26182/files
  - new: https://git.openjdk.org/jdk/pull/26182/files/5e22da78..1e524119

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

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

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

From tschatzl at openjdk.org  Tue Jul  8 11:31:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Jul 2025 11:31:38 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v2]
In-Reply-To: <s87mCiPyGQdFOI5jyUA5xlh5CXoAQsGkMlRvNiEMk0k=.3eabc110-d856-461e-9328-8f520491f8b8@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
 <s87mCiPyGQdFOI5jyUA5xlh5CXoAQsGkMlRvNiEMk0k=.3eabc110-d856-461e-9328-8f520491f8b8@github.com>
Message-ID: <9OVV3XIp3koLYRJAGDje6hJLB7CNXjicwJvHQzMl2M4=.254e783e-7701-4c0f-acc9-3f1795cd070f@github.com>

On Tue, 8 Jul 2025 10:13:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
>> 
>> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental comment removal

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26182#pullrequestreview-2997204680

From tschatzl at openjdk.org  Tue Jul  8 12:10:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Jul 2025 12:10:38 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v2]
In-Reply-To: <s87mCiPyGQdFOI5jyUA5xlh5CXoAQsGkMlRvNiEMk0k=.3eabc110-d856-461e-9328-8f520491f8b8@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
 <s87mCiPyGQdFOI5jyUA5xlh5CXoAQsGkMlRvNiEMk0k=.3eabc110-d856-461e-9328-8f520491f8b8@github.com>
Message-ID: <BLS9jrFzSQ-oFVJ6jcwTCQ8WAKC7Not9ZNZVqK7HCq8=.9f947193-5cd6-47f7-b3da-3dedd1cd543b@github.com>

On Tue, 8 Jul 2025 10:13:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
>> 
>> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental comment removal

Maybe also related to [JDK-8343047](https://bugs.openjdk.org/browse/JDK-8343047)?

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

PR Comment: https://git.openjdk.org/jdk/pull/26182#issuecomment-3048660466

From shade at openjdk.org  Tue Jul  8 13:28:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 13:28:42 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `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 non-null bits of the forwardee (whether it spills into the nKlass bits), 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.

You know what, this is fine as it is.

The whole business with `ShenandoahForwarding::klass` is super-duper-awkward, and verifier already touches the forwardees using that method in places where it really should not. It needs a more comprehensive fix for `+UCOH`.

It is a mess, but not your mess. So integrate this one, we will figure out `ShenandoahForwarding::klass` after this.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26117#pullrequestreview-2997654169

From shade at openjdk.org  Tue Jul  8 13:35:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 13:35:38 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v2]
In-Reply-To: <BLS9jrFzSQ-oFVJ6jcwTCQ8WAKC7Not9ZNZVqK7HCq8=.9f947193-5cd6-47f7-b3da-3dedd1cd543b@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
 <s87mCiPyGQdFOI5jyUA5xlh5CXoAQsGkMlRvNiEMk0k=.3eabc110-d856-461e-9328-8f520491f8b8@github.com>
 <BLS9jrFzSQ-oFVJ6jcwTCQ8WAKC7Not9ZNZVqK7HCq8=.9f947193-5cd6-47f7-b3da-3dedd1cd543b@github.com>
Message-ID: <8hGy3yJtJbwfJo79G7xZhwfoDOaoRNi8Klh1bALE5HU=.6ad6f450-120b-4f31-b857-94ef7c51b8dc@github.com>

On Tue, 8 Jul 2025 12:07:57 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Maybe also related to [JDK-8343047](https://bugs.openjdk.org/browse/JDK-8343047)?

Maybe. The first iteration of the benchmark is very noisy, as it IMO heavily depends on initial heap conditions at benchmark start. For a mark-compact, a small dead or alive object near the bottom of the heap may be a difference between a substantial heap move, or hardly any moves at all. Throw in multithreaded work balancing, and things get even more interesting. This is why there is `System.gc()` in `@Setup` now, so that we get into the same heap conditions before we go for a "real" benchmarked `System.gc()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26182#issuecomment-3048988773

From mbaesken at openjdk.org  Tue Jul  8 13:36:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Jul 2025 13:36:57 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside the
 range of representable values issue
Message-ID: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>

When running the jtreg test
gc/z/TestMappedCacheHarvest.java
with ubsan-enabled binaries on macOS aarch64, we following ubsan error is reported :


 stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
    #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
    #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
    #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
    #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
    #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
    #5 0x109ce770c in Thread::call_run() thread.cpp:243
    #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
    #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
    #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)


After I added a bit of tracing to `select_worker_threads` and it seems we get WAY too high young_to_old_ratio values; in my locally failing example
young_to_old_ratio:27561965412.478878
this leads to values out of range of uint and that makes ubsan complain about the uint cast 
`uint(young_workers * young_to_old_ratio)` .
We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

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

Commit messages:
 - JDK-8360817

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

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

From shade at openjdk.org  Tue Jul  8 13:48:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 13:48:39 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v2]
In-Reply-To: <s87mCiPyGQdFOI5jyUA5xlh5CXoAQsGkMlRvNiEMk0k=.3eabc110-d856-461e-9328-8f520491f8b8@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
 <s87mCiPyGQdFOI5jyUA5xlh5CXoAQsGkMlRvNiEMk0k=.3eabc110-d856-461e-9328-8f520491f8b8@github.com>
Message-ID: <gqTyw7VN3r8_dtyWyyHWhkM9J5Vr4dYFHkzGGDy7ZE4=.7510d097-857c-4495-99d0-af66fd5a6352@github.com>

On Tue, 8 Jul 2025 10:13:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
>> 
>> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental comment removal

Now that I am thinking about it, maybe we should just put `System.gc()` into `@Setup(Level.Trial)`, so we don't overdo it every iteration. Let me try...

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

PR Comment: https://git.openjdk.org/jdk/pull/26182#issuecomment-3049033721

From stuefe at openjdk.org  Tue Jul  8 13:48:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Jul 2025 13:48:40 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
 <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>
Message-ID: <E2AFZRuplK_3qEuT7diemMZs8vkRwEMo6nBjHMJv_PE=.4a37a806-b3ce-4991-b15f-fde49d73ca43@github.com>

On Tue, 8 Jul 2025 13:25:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> You know what, this is fine as it is.
> 
> The whole business with `ShenandoahForwarding::klass` is super-duper-awkward, and verifier already touches the forwardees using that method in places where it really should not. It needs a more comprehensive fix for `+UCOH`.
> 
> It is a mess, but not your mess. So integrate this one, we will figure out `ShenandoahForwarding::klass` after this.

I had a similar thought while working on https://bugs.openjdk.org/browse/JDK-8361342 . `ShenandoahForwarding::klass` resolves the narrow Klass pointer, which may already assert if that one is null or invalid. I mentally left it for a rainy friday afternoon to fix.

And yes, printing the raw header (and possibly the first few payload words, to get a bit of the first members) I found very useful. os::print_hex_dump will tiptoe around invalid memory, so that should be fine to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/26117#issuecomment-3049039918

From shade at openjdk.org  Tue Jul  8 14:29:08 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 14:29:08 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v3]
In-Reply-To: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
Message-ID: <rLCYanEPV0yIhf_y7ct8htF_Dup2aeVnqWGadUCoR5Y=.9e785193-23b9-41d4-9714-b182480cf2da@github.com>

> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
> 
> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs

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

 - Revert accidental
 - Merge branch 'master' into JDK-8361520-stabilize-systemgc
 - Do System.gc() once at start
 - Revert accidental comment removal
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26182/files
  - new: https://git.openjdk.org/jdk/pull/26182/files/1e524119..bfafa46a

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

  Stats: 1109 lines in 74 files changed: 602 ins; 129 del; 378 mod
  Patch: https://git.openjdk.org/jdk/pull/26182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26182/head:pull/26182

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

From shade at openjdk.org  Tue Jul  8 14:29:08 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 14:29:08 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v2]
In-Reply-To: <gqTyw7VN3r8_dtyWyyHWhkM9J5Vr4dYFHkzGGDy7ZE4=.7510d097-857c-4495-99d0-af66fd5a6352@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
 <s87mCiPyGQdFOI5jyUA5xlh5CXoAQsGkMlRvNiEMk0k=.3eabc110-d856-461e-9328-8f520491f8b8@github.com>
 <gqTyw7VN3r8_dtyWyyHWhkM9J5Vr4dYFHkzGGDy7ZE4=.7510d097-857c-4495-99d0-af66fd5a6352@github.com>
Message-ID: <Vy0VwXb650Hz6IbutCmdm40E6-e_imXZn55Hf3szqa8=.0fd1a7dc-6a5f-4145-9838-b9750bb59de2@github.com>

On Tue, 8 Jul 2025 13:44:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that I am thinking about it, maybe we should just put `System.gc()` into `@Setup(Level.Trial)`, so we don't overdo it every iteration. Let me try...

Yeah, that works too, and it is a little more efficient. Updated the perf data in last comment: https://github.com/openjdk/jdk/pull/26182#issuecomment-3048014191

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

PR Comment: https://git.openjdk.org/jdk/pull/26182#issuecomment-3049187063

From stuefe at openjdk.org  Tue Jul  8 14:59:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Jul 2025 14:59:49 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror object
 after JDK-8340297
Message-ID: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>

Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 

This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.

For details about this issue, please see the Jira description and comment. The short version is:
- class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
- but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
- But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.

I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.

Therefore I just changed the assertions.

But I would like to hear other people's opinion on this.

Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

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

Commit messages:
 - also fix ShenandoahVerifier
 - start

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

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

From stuefe at openjdk.org  Tue Jul  8 14:59:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Jul 2025 14:59:49 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <sackfq8w9KfzanWVvTwWdBUeR09fu-zAQOyBn0tJsLY=.d0cc8c2c-1acb-478d-b483-44d50a265d88@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

Ping @shipilev or @rkennke?

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3049289071

From tschatzl at openjdk.org  Tue Jul  8 15:13:59 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Jul 2025 15:13:59 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
Message-ID: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>

Hi all,

  please review this change to avoid CodeCache triggered GCs temporarily being ignored.

In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).

The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).

So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.

Testing: tier1-5, test case passing, failing before

Thanks,
  Thomas

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

Commit messages:
 - * some whitespace fixes
 - 8350621

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

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

From shade at openjdk.org  Tue Jul  8 15:24:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 15:24:38 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <RadK77QLt6Nwqgxpn39SzuI6jJfCny9d_7pJoSFNK9Q=.d570b367-f213-4253-9cf5-7d65dcd8d0b8@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

Only looked at this briefly, but that sounds like what I did here: https://github.com/openjdk/jdk/pull/21064 -- but forgot to complete it?

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3049385835

From shade at openjdk.org  Tue Jul  8 16:32:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 16:32:38 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

> Only looked at this briefly, but that sounds like what I did here: #21064 -- but forgot to complete it?

Yes, it looks like it is! The sequence of events you describe seems to also match [JDK-8340364](https://bugs.openjdk.org/browse/JDK-8340364). So, what do you want to do? I can finish up #21064 and test it with your Metaspace assertion patches, if you want.

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3049592995

From wkemper at openjdk.org  Tue Jul  8 17:45:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 17:45:40 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <0RUevGLqg0w1Cx1B9IWhTuNc0ag4FoLfSLEL5_xFcO8=.d65405d3-e713-4c94-a147-89e20dfe13bd@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 274:

> 272:     // During class redefinition the old Klass gets reclaimed and the old mirror oop's Klass reference
> 273:     // nulled out (hence the "klass != nullptr" condition below). However, the mirror oop may have been
> 274:     // forwarded if we are in the mids of an evacuation. In that case, the forwardee's Klass reference

s/mids/midst

src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 275:

> 273:     // nulled out (hence the "klass != nullptr" condition below). However, the mirror oop may have been
> 274:     // forwarded if we are in the mids of an evacuation. In that case, the forwardee's Klass reference
> 275:     // is nulled out. The old, forwarded, still still carries the old invalid Klass pointer. It will be

s/still still/still

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26187#discussion_r2193102294
PR Review Comment: https://git.openjdk.org/jdk/pull/26187#discussion_r2193102793

From wkemper at openjdk.org  Tue Jul  8 17:52:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 17:52:37 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

The explanation and the changes make sense to me. Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3049812331

From kdnilsen at openjdk.org  Tue Jul  8 17:54:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 8 Jul 2025 17:54:22 GMT
Subject: RFR: 8361529: GenShen: Fix bad assert in swap card tables
Message-ID: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>

The end of range for card marks checked by assert needs to be based from the base of the card table rather than the mapped base of the card table.

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

Commit messages:
 - Assert from byte_map rather than byte_map_base
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 29 more: https://git.openjdk.org/jdk/compare/197fde53...8177e148

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

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

From wkemper at openjdk.org  Tue Jul  8 17:59:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 17:59:39 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v5]
In-Reply-To: <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@github.com>
Message-ID: <eQVaICGtfLEi5NtlKNbwPNBShEPv6ao93LaMi5VOzBQ=.e5714f13-8c52-4176-b1dd-85e225ea89f7@github.com>

On Tue, 8 Jul 2025 00:23:55 GMT, Rui Li <duke at openjdk.org> wrote:

>> 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:
> 
>   Use comment style

This is a nice simplification. Thank you!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25943#pullrequestreview-2998614615

From wkemper at openjdk.org  Tue Jul  8 18:17:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 18:17:40 GMT
Subject: RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>
References: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>
Message-ID: <UG8xCkKAbqOfJXOUM3U_PeBeOX5tzSLUEWlhZ7s-tEM=.325213e8-9b1d-44d7-bf8c-8ebef6cc08e9@github.com>

On Tue, 8 Jul 2025 17:40:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> The end of range for card marks checked by assert needs to be based from the base of the card table rather than the mapped base of the card table.

Good catch!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26197#pullrequestreview-2998661511

From duke at openjdk.org  Tue Jul  8 18:33:41 2025
From: duke at openjdk.org (duke)
Date: Tue, 8 Jul 2025 18:33:41 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v5]
In-Reply-To: <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@github.com>
Message-ID: <733Feokyp2nA9L6Gu8hBAVEg6uhleOVN8HkVt5xnpIM=.b0385894-f08f-4f18-8964-e3d468f844dc@github.com>

On Tue, 8 Jul 2025 00:23:55 GMT, Rui Li <duke at openjdk.org> wrote:

>> 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:
> 
>   Use comment style

@rgithubli 
Your change (at version 8e0b1f21baf44566b5a6fd96af4fc1baf8bbefa3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25943#issuecomment-3049924125

From duke at openjdk.org  Tue Jul  8 18:36:44 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 18:36:44 GMT
Subject: Integrated: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <xamUMOWREx--ZFvSA8rOikbW27p-19hWkZZ_m2FqS9o=.1acdd5dc-e57f-40a5-94e8-2771c5b235e4@github.com>

On Mon, 23 Jun 2025 21:42:36 GMT, Rui Li <duke at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: fa32bfe1
Author:    Rui Li <ruiamzn at amazon.com>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa32bfe11300fdadb35f083037f6ab2a8985d210
Stats:     177 lines in 17 files changed: 78 ins; 32 del; 67 mod

8358529: GenShen: Heuristics do not respond to changes in SoftMaxHeapSize

Reviewed-by: wkemper

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

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

From kdnilsen at openjdk.org  Tue Jul  8 19:01:55 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 8 Jul 2025 19:01:55 GMT
Subject: Integrated: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>
References: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>
Message-ID: <3jFy8asl8ptBrD-YW-MzccYdjeLYaAPPVzzo_DC2Spc=.41194616-4de3-4c7c-a25c-9dece2c7d433@github.com>

On Tue, 8 Jul 2025 17:40:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> The end of range for card marks checked by assert needs to be based from the base of the card table rather than the mapped base of the card table.

This pull request has now been integrated.

Changeset: 1de2acea
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1de2acea77da57fd44b214332a73cc6621806e4d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361529: GenShen: Fix bad assert in swap card tables

Reviewed-by: wkemper

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

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

From tschatzl at openjdk.org  Tue Jul  8 19:23:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Jul 2025 19:23:47 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
References: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
Message-ID: <6XGOkpJ4gQxTjKwvm4VRqo-oqdNdAO4_yMdf9t4U7Tg=.e47311a8-9db6-402e-849e-10e2b1664ad9@github.com>

On Sun, 16 Feb 2025 18:39:29 GMT, Alexandre Jacob <duke at openjdk.org> wrote:

> The purpose of this PR is to fix a bug where we can end up in a situation where the GC is not scheduled anymore by `CodeCache`.
> 
> This situation is possible because the `_unloading_threshold_gc_requested` flag is set to `true` when triggering the GC and we expect the GC to call `CodeCache::on_gc_marking_cycle_finish` which in turn will call `CodeCache::update_cold_gc_count`, which will reset the flag `_unloading_threshold_gc_requested` allowing further GC scheduling.
> 
> Unfortunately this can't work properly under certain circumstances.
> For example, if using G1GC, calling `G1CollectedHeap::collect` does no give the guarantee that the GC will actually run as it can be already running (see [here](https://github.com/openjdk/jdk/blob/7d11418c820b46926a25907766d16083a4b349de/src/hotspot/share/gc/g1/g1CollectedHeap.cpp#L1763)).
> 
> I have observed this behavior on JVM in version 21 that were migrated recently from java 17.
> Those JVMs have some pressure on code cache and quite a large heap in comparison to allocation rate, which means that objects are mostly GC'd by young collections and full GC take a long time to happen.
> 
> I have been able to reproduce this issue with ParallelGC and G1GC, and I imagine that other GC can be impacted as well.
> 
> In order to reproduce this issue, I found a very simple and convenient way:
> 
> 
> public class CodeCacheMain {
>     public static void main(String[] args) throws InterruptedException {
>         while (true) {
>             Thread.sleep(100);
>         }
>     }
> }
> 
> 
> Run this simple app with the following JVM flags:
> 
> 
> -Xlog:gc*=info,codecache=info -Xmx512m -XX:ReservedCodeCacheSize=2496k -XX:StartAggressiveSweepingAt=15
> 
> 
> - 512m for the heap just to clarify the intent that we don't want to be bothered by a full GC
> - low `ReservedCodeCacheSize` to put pressure on code cache quickly
> - `StartAggressiveSweepingAt` can be set to 20 or 15 for faster bug reproduction
> 
> Itself, the program will hardly get pressure on code cache, but the good news is that it is sufficient to attach a jconsole on it which will:
> - allows us to monitor code cache
> - indirectly generate activity on the code cache, just what we need to reproduce the bug
> 
> Some logs related to code cache will show up at some point with GC activity:
> 
> 
> [648.733s][info][codecache      ] Triggering aggressive GC due to having only 14.970% free memory
> 
> 
> And then it will stop and we'll end up with the following message:
> 
> 
> [672.714s][info][codecache      ] Code cache is full - disabling compilation
> 
> 
> L...

We discussed this question internally bit, and the consensus has been to use a new PR to avoid confusion due to two different approaches being discussed in the same thread. Would you mind closing this one out and I'll create a new PR?

Thanks,
  Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/23656#issuecomment-3049289764

From duke at openjdk.org  Tue Jul  8 19:23:48 2025
From: duke at openjdk.org (Alexandre Jacob)
Date: Tue, 8 Jul 2025 19:23:48 GMT
Subject: Withdrawn: 8350621: Code cache stops scheduling GC
In-Reply-To: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
References: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
Message-ID: <K2EBeKBsBZoo1hVQG_KwZMw7NK3WjtGAheATZXMIFL8=.14c8023a-7543-4e8e-a692-c3f47b9b8bb8@github.com>

On Sun, 16 Feb 2025 18:39:29 GMT, Alexandre Jacob <duke at openjdk.org> wrote:

> The purpose of this PR is to fix a bug where we can end up in a situation where the GC is not scheduled anymore by `CodeCache`.
> 
> This situation is possible because the `_unloading_threshold_gc_requested` flag is set to `true` when triggering the GC and we expect the GC to call `CodeCache::on_gc_marking_cycle_finish` which in turn will call `CodeCache::update_cold_gc_count`, which will reset the flag `_unloading_threshold_gc_requested` allowing further GC scheduling.
> 
> Unfortunately this can't work properly under certain circumstances.
> For example, if using G1GC, calling `G1CollectedHeap::collect` does no give the guarantee that the GC will actually run as it can be already running (see [here](https://github.com/openjdk/jdk/blob/7d11418c820b46926a25907766d16083a4b349de/src/hotspot/share/gc/g1/g1CollectedHeap.cpp#L1763)).
> 
> I have observed this behavior on JVM in version 21 that were migrated recently from java 17.
> Those JVMs have some pressure on code cache and quite a large heap in comparison to allocation rate, which means that objects are mostly GC'd by young collections and full GC take a long time to happen.
> 
> I have been able to reproduce this issue with ParallelGC and G1GC, and I imagine that other GC can be impacted as well.
> 
> In order to reproduce this issue, I found a very simple and convenient way:
> 
> 
> public class CodeCacheMain {
>     public static void main(String[] args) throws InterruptedException {
>         while (true) {
>             Thread.sleep(100);
>         }
>     }
> }
> 
> 
> Run this simple app with the following JVM flags:
> 
> 
> -Xlog:gc*=info,codecache=info -Xmx512m -XX:ReservedCodeCacheSize=2496k -XX:StartAggressiveSweepingAt=15
> 
> 
> - 512m for the heap just to clarify the intent that we don't want to be bothered by a full GC
> - low `ReservedCodeCacheSize` to put pressure on code cache quickly
> - `StartAggressiveSweepingAt` can be set to 20 or 15 for faster bug reproduction
> 
> Itself, the program will hardly get pressure on code cache, but the good news is that it is sufficient to attach a jconsole on it which will:
> - allows us to monitor code cache
> - indirectly generate activity on the code cache, just what we need to reproduce the bug
> 
> Some logs related to code cache will show up at some point with GC activity:
> 
> 
> [648.733s][info][codecache      ] Triggering aggressive GC due to having only 14.970% free memory
> 
> 
> And then it will stop and we'll end up with the following message:
> 
> 
> [672.714s][info][codecache      ] Code cache is full - disabling compilation
> 
> 
> L...

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Jul  8 19:23:48 2025
From: duke at openjdk.org (Alexandre Jacob)
Date: Tue, 8 Jul 2025 19:23:48 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
References: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
Message-ID: <TusuZWMLb-WVSXPi_Cgy-P7wc4fB7RI2tu7tQ8LfOXI=.096f5beb-f388-4551-8af1-f14653039f2a@github.com>

On Sun, 16 Feb 2025 18:39:29 GMT, Alexandre Jacob <duke at openjdk.org> wrote:

> The purpose of this PR is to fix a bug where we can end up in a situation where the GC is not scheduled anymore by `CodeCache`.
> 
> This situation is possible because the `_unloading_threshold_gc_requested` flag is set to `true` when triggering the GC and we expect the GC to call `CodeCache::on_gc_marking_cycle_finish` which in turn will call `CodeCache::update_cold_gc_count`, which will reset the flag `_unloading_threshold_gc_requested` allowing further GC scheduling.
> 
> Unfortunately this can't work properly under certain circumstances.
> For example, if using G1GC, calling `G1CollectedHeap::collect` does no give the guarantee that the GC will actually run as it can be already running (see [here](https://github.com/openjdk/jdk/blob/7d11418c820b46926a25907766d16083a4b349de/src/hotspot/share/gc/g1/g1CollectedHeap.cpp#L1763)).
> 
> I have observed this behavior on JVM in version 21 that were migrated recently from java 17.
> Those JVMs have some pressure on code cache and quite a large heap in comparison to allocation rate, which means that objects are mostly GC'd by young collections and full GC take a long time to happen.
> 
> I have been able to reproduce this issue with ParallelGC and G1GC, and I imagine that other GC can be impacted as well.
> 
> In order to reproduce this issue, I found a very simple and convenient way:
> 
> 
> public class CodeCacheMain {
>     public static void main(String[] args) throws InterruptedException {
>         while (true) {
>             Thread.sleep(100);
>         }
>     }
> }
> 
> 
> Run this simple app with the following JVM flags:
> 
> 
> -Xlog:gc*=info,codecache=info -Xmx512m -XX:ReservedCodeCacheSize=2496k -XX:StartAggressiveSweepingAt=15
> 
> 
> - 512m for the heap just to clarify the intent that we don't want to be bothered by a full GC
> - low `ReservedCodeCacheSize` to put pressure on code cache quickly
> - `StartAggressiveSweepingAt` can be set to 20 or 15 for faster bug reproduction
> 
> Itself, the program will hardly get pressure on code cache, but the good news is that it is sufficient to attach a jconsole on it which will:
> - allows us to monitor code cache
> - indirectly generate activity on the code cache, just what we need to reproduce the bug
> 
> Some logs related to code cache will show up at some point with GC activity:
> 
> 
> [648.733s][info][codecache      ] Triggering aggressive GC due to having only 14.970% free memory
> 
> 
> And then it will stop and we'll end up with the following message:
> 
> 
> [672.714s][info][codecache      ] Code cache is full - disabling compilation
> 
> 
> L...

Sure I can close this PR, this makes things simpler for everybody I guess!

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

PR Comment: https://git.openjdk.org/jdk/pull/23656#issuecomment-3050053298

From duke at openjdk.org  Tue Jul  8 22:02:04 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 22:02:04 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not use
 SoftMaxHeapSize
Message-ID: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>

Shenandoah some of the usages of [ShenandoahMinFreeThreshold](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L193) and [ShenandoahCriticalFreeThreshold](https://github.com/openjdk/jdk/blob/ba0c12231b0f5b680951e75765b5d292f31a2cbc/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L445) use max capacity instead of [soft max capacity](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gc_globals.hpp#L528). 

This change replaces those usages with soft max heap size values.

tier1 tests are in progress

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

Commit messages:
 - Fix after 8358529
 - 8359868: Shenandoah: Free threshold heuristic does not use SoftMaxHeapSize

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

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

From wkemper at openjdk.org  Tue Jul  8 22:02:05 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 22:02:05 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not
 use SoftMaxHeapSize
In-Reply-To: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
References: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
Message-ID: <TPAhBi99vhUp7fPcy9e-xfpS681bJeSlaaTYmTmfHJc=.9f12b69e-d6ba-43d4-ae80-f6afeacddace@github.com>

On Tue, 8 Jul 2025 18:42:49 GMT, Rui Li <duke at openjdk.org> wrote:

> Shenandoah some of the usages of [ShenandoahMinFreeThreshold](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L193) and [ShenandoahCriticalFreeThreshold](https://github.com/openjdk/jdk/blob/ba0c12231b0f5b680951e75765b5d292f31a2cbc/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L445) use max capacity instead of [soft max capacity](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gc_globals.hpp#L528). 
> 
> This change replaces those usages with soft max heap size values.
> 
> tier1 tests are in progress

LGTM. Thank you!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26199#pullrequestreview-2999155933

From duke at openjdk.org  Tue Jul  8 22:02:05 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 22:02:05 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not
 use SoftMaxHeapSize
In-Reply-To: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
References: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
Message-ID: <gy-9QbsF4gZK5n-U1u12LR2Ucbvit05gTpuQHZWECQc=.a74eefab-7f55-40c4-a77b-5764eef05b84@github.com>

On Tue, 8 Jul 2025 18:42:49 GMT, Rui Li <duke at openjdk.org> wrote:

> Shenandoah some of the usages of [ShenandoahMinFreeThreshold](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L193) and [ShenandoahCriticalFreeThreshold](https://github.com/openjdk/jdk/blob/ba0c12231b0f5b680951e75765b5d292f31a2cbc/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L445) use max capacity instead of [soft max capacity](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gc_globals.hpp#L528). 
> 
> This change replaces those usages with soft max heap size values.
> 
> tier1 tests are in progress

Moved to ready for review a bit late - after the approval. Checking if integrating now works.

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

PR Comment: https://git.openjdk.org/jdk/pull/26199#issuecomment-3050396990

From duke at openjdk.org  Tue Jul  8 22:02:05 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 22:02:05 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not use
 SoftMaxHeapSize
In-Reply-To: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
References: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
Message-ID: <zhwvV1N11d0rkGB4FNlLkLCZwk1muMefK2hBBLa-WH8=.021b47e7-2bb3-4c80-b202-6c9ad0332be9@github.com>

On Tue, 8 Jul 2025 18:42:49 GMT, Rui Li <duke at openjdk.org> wrote:

> Shenandoah some of the usages of [ShenandoahMinFreeThreshold](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L193) and [ShenandoahCriticalFreeThreshold](https://github.com/openjdk/jdk/blob/ba0c12231b0f5b680951e75765b5d292f31a2cbc/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L445) use max capacity instead of [soft max capacity](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gc_globals.hpp#L528). 
> 
> This change replaces those usages with soft max heap size values.
> 
> tier1 tests are in progress

This pull request has now been integrated.

Changeset: 974ad4e8
Author:    Rui Li <ruiamzn at amazon.com>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/974ad4e8cdddee7d932e8375258067f9d2ca6a8b
Stats:     7 lines in 4 files changed: 0 ins; 3 del; 4 mod

8359868: Shenandoah: Free threshold heuristic does not use SoftMaxHeapSize

Reviewed-by: wkemper

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

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

From stuefe at openjdk.org  Wed Jul  9 05:19:48 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Jul 2025 05:19:48 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
 <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>
Message-ID: <o6I93nN_bT12qouiR7QA0APFhHhFOyMgCk9z2WMwNfU=.753b2e16-6072-4e9b-9cbb-9acc6183a573@github.com>

On Tue, 8 Jul 2025 13:25:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `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 non-null bits of the forwardee (whether it spills into the nKlass bits), 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.
>
> You know what, this is fine as it is.
> 
> The whole business with `ShenandoahForwarding::klass` is super-duper-awkward, and verifier already touches the forwardees using that method in places where it really should not. It needs a more comprehensive fix for `+UCOH`.
> 
> It is a mess, but not your mess. So integrate this one, we will figure out `ShenandoahForwarding::klass` after this.

Thanks @shipilev and @rkennke !

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

PR Comment: https://git.openjdk.org/jdk/pull/26117#issuecomment-3051146037

From stuefe at openjdk.org  Wed Jul  9 05:19:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Jul 2025 05:19:49 GMT
Subject: Integrated: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <ts4-L7hoQP_2gNsFhU34lch1o5zxmfxfnBBNaK_hklQ=.06b16178-8a12-41fd-b07b-4bb070628adb@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `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 non-null bits of the forwardee (whether it spills into the nKlass bits), 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.

This pull request has now been integrated.

Changeset: fe264676
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe264676337cdef0d7477b0b57ff9d2fe8f9fc0f
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8361363: ShenandoahAsserts::print_obj() does not work for forwarded objects and UseCompactObjectHeaders

Reviewed-by: rkennke, shade

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

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

From iwalulya at openjdk.org  Wed Jul  9 05:47:46 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 9 Jul 2025 05:47:46 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v11]
In-Reply-To: <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>
Message-ID: <pM3HQiqjxi0bEcBHzQKnfNDRHsnKDl8H6eNuoXse24A=.0ff26f2c-fe27-419f-9d78-d4213947e074@github.com>

On Fri, 4 Jul 2025 15:28:20 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 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

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25832#issuecomment-3051200761

From iwalulya at openjdk.org  Wed Jul  9 05:47:46 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 9 Jul 2025 05:47:46 GMT
Subject: Integrated: 8238687: Investigate memory uncommit during young
 collections in G1
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <GSwg0kaThNVgfe9QNfcZU84493ZOkEXpBntXbI7MCTQ=.c9da7cb3-c864-45f6-b649-0aa50d7f9f55@github.com>

On Mon, 16 Jun 2025 14:05:52 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 Tier 1-7

This pull request has now been integrated.

Changeset: 47614796
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4761479608d5a8ecc504e343109900b0d0c77171
Stats:     618 lines in 16 files changed: 395 ins; 89 del; 134 mod

8238687: Investigate memory uncommit during young collections in G1
8247843: Reconsider G1 default GCTimeRatio value
8248324: G1: Remove resizing during Remark

Co-authored-by: Thomas Schatzl <tschatzl at openjdk.org>
Reviewed-by: kbarrett, tschatzl

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

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

From tschatzl at openjdk.org  Wed Jul  9 07:46:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 07:46:53 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
References: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
Message-ID: <ySmr2mnKZXQKcc_up4BKwRwl6dKeqAu_odwvilUz2tQ=.76fd623b-bde4-4f23-8b30-4634fe322b1a@github.com>

On Sun, 16 Feb 2025 18:39:29 GMT, Alexandre Jacob <duke at openjdk.org> wrote:

> The purpose of this PR is to fix a bug where we can end up in a situation where the GC is not scheduled anymore by `CodeCache`.
> 
> This situation is possible because the `_unloading_threshold_gc_requested` flag is set to `true` when triggering the GC and we expect the GC to call `CodeCache::on_gc_marking_cycle_finish` which in turn will call `CodeCache::update_cold_gc_count`, which will reset the flag `_unloading_threshold_gc_requested` allowing further GC scheduling.
> 
> Unfortunately this can't work properly under certain circumstances.
> For example, if using G1GC, calling `G1CollectedHeap::collect` does no give the guarantee that the GC will actually run as it can be already running (see [here](https://github.com/openjdk/jdk/blob/7d11418c820b46926a25907766d16083a4b349de/src/hotspot/share/gc/g1/g1CollectedHeap.cpp#L1763)).
> 
> I have observed this behavior on JVM in version 21 that were migrated recently from java 17.
> Those JVMs have some pressure on code cache and quite a large heap in comparison to allocation rate, which means that objects are mostly GC'd by young collections and full GC take a long time to happen.
> 
> I have been able to reproduce this issue with ParallelGC and G1GC, and I imagine that other GC can be impacted as well.
> 
> In order to reproduce this issue, I found a very simple and convenient way:
> 
> 
> public class CodeCacheMain {
>     public static void main(String[] args) throws InterruptedException {
>         while (true) {
>             Thread.sleep(100);
>         }
>     }
> }
> 
> 
> Run this simple app with the following JVM flags:
> 
> 
> -Xlog:gc*=info,codecache=info -Xmx512m -XX:ReservedCodeCacheSize=2496k -XX:StartAggressiveSweepingAt=15
> 
> 
> - 512m for the heap just to clarify the intent that we don't want to be bothered by a full GC
> - low `ReservedCodeCacheSize` to put pressure on code cache quickly
> - `StartAggressiveSweepingAt` can be set to 20 or 15 for faster bug reproduction
> 
> Itself, the program will hardly get pressure on code cache, but the good news is that it is sufficient to attach a jconsole on it which will:
> - allows us to monitor code cache
> - indirectly generate activity on the code cache, just what we need to reproduce the bug
> 
> Some logs related to code cache will show up at some point with GC activity:
> 
> 
> [648.733s][info][codecache      ] Triggering aggressive GC due to having only 14.970% free memory
> 
> 
> And then it will stop and we'll end up with the following message:
> 
> 
> [672.714s][info][codecache      ] Code cache is full - disabling compilation
> 
> 
> L...

Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/23656#issuecomment-3051539837

From ayang at openjdk.org  Wed Jul  9 08:06:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 08:06:23 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v21]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <hcfjkZ-UhUTC3bppfRX14ywIdvRvSXoiXMpAZRfxfL4=.00d16c06-4b13-49d9-8fe5-3d0059fe2e56@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 32 commits:

 - Merge branch 'master' into pgc-size-policy
 - review
 - 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
 - ... and 22 more: https://git.openjdk.org/jdk/compare/117f0b40...0d5de9a2

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=20
  Stats: 4362 lines in 31 files changed: 507 ins; 3470 del; 385 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  Wed Jul  9 08:06:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 08:06:23 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <eVepnCg32apDKXAn7rezipT5YRqLa8c-cjjARftsnoQ=.e90c58d3-ba06-41c1-9cd5-94ba49e322a2@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>
 <eVepnCg32apDKXAn7rezipT5YRqLa8c-cjjARftsnoQ=.e90c58d3-ba06-41c1-9cd5-94ba49e322a2@github.com>
Message-ID: <-tg-l6DOtno0KEnAIgMPSuWLoHZLtJnTdj4BRLUnGpo=.be889c98-761f-416c-bd74-e2d3986db1b7@github.com>

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

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

I took another look at this and realized that there are to paths to do retry-allocation-in-old-gen-after-young-gen-failure.

1. In `mem_allocate_work`.


      HeapWord* result = young_gen()->allocate(size);
      if (result != nullptr) {
        return result;
      }

      // If certain conditions hold, try allocating from the old gen.
      if (!is_tlab && !should_alloc_in_eden(size)) {
        result = old_gen()->cas_allocate_noexpand(size);


This retry-allocation-in-old-gen is *pre-gc* -- the `should_alloc_in_eden` filter is there to ensure that a (young) gc should kick-in, instead of populating old-gen with many small objs.

2. In `satisfy_failed_allocation` -> `expand_heap_and_allocate`.


  HeapWord* result = young_gen()->expand_and_allocate(size);

  if (result == nullptr && !is_tlab) {
    result = old_gen()->expand_and_allocate(size);
  }


This retry-allocation-in-old-gen is *post-gc* -- we should not artificially introduce old-gen-allocation-failure, because that would mean the previous (young/full) gc was useless to this allocation-request.

Therefore, I believe the logic on master is more reasonable. Also, for back compatibility reasons, I have reverted this part and added a comment there.

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

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

From tschatzl at openjdk.org  Wed Jul  9 08:10:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 08:10:44 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v3]
In-Reply-To: <rLCYanEPV0yIhf_y7ct8htF_Dup2aeVnqWGadUCoR5Y=.9e785193-23b9-41d4-9714-b182480cf2da@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
 <rLCYanEPV0yIhf_y7ct8htF_Dup2aeVnqWGadUCoR5Y=.9e785193-23b9-41d4-9714-b182480cf2da@github.com>
Message-ID: <IjmEXkBNFC8Z6gVy23DLSEzBZ39ud6XDlJqz2i6IeP8=.3fabfc3d-91ee-49fa-b286-60d3f4821716@github.com>

On Tue, 8 Jul 2025 14:29:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
>> 
>> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Revert accidental
>  - Merge branch 'master' into JDK-8361520-stabilize-systemgc
>  - Do System.gc() once at start
>  - Revert accidental comment removal
>  - Fix

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26182#pullrequestreview-3000500000

From tschatzl at openjdk.org  Wed Jul  9 08:13:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 08:13:44 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v3]
In-Reply-To: <c_fGFeNrF5ysBpWriB_1eA7IoLpvMTCBIApTGpkMKno=.8a22f725-c1af-4296-9913-a1f7d387ac58@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
 <c_fGFeNrF5ysBpWriB_1eA7IoLpvMTCBIApTGpkMKno=.8a22f725-c1af-4296-9913-a1f7d387ac58@github.com>
Message-ID: <Rd6fTIm7N9RtME9nhSq_1e3OQ36Q0869bZ8-m8-mzNQ=.68368e7b-9158-419b-84ca-2a0dc8b30dd2@github.com>

On Mon, 7 Jul 2025 14:01:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * remove one more unnecessary `private`
>
> Marked as reviewed by ayang (Reviewer).

Thank you for your reviews @albertnetymk @walulyai @abdelhak-zaaim .

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

PR Comment: https://git.openjdk.org/jdk/pull/26160#issuecomment-3051613953

From tschatzl at openjdk.org  Wed Jul  9 08:13:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 08:13:45 GMT
Subject: Integrated: 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: <NzlPXpMLoA_832saZAH_8ylu-lBkyc6jUR1GQWeiWcI=.6e85fb3c-354f-43d7-9eaa-03ad90f289a2@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

This pull request has now been integrated.

Changeset: 68b27b88
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68b27b88b5160dd2883f93928c5f6ce245412495
Stats:     52 lines in 8 files changed: 27 ins; 25 del; 0 mod

8361349: Fix visibility of CollectedHeap::stop() and ::print_tracing_info()

Reviewed-by: iwalulya, ayang

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

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

From ayang at openjdk.org  Wed Jul  9 08:21:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 08:21:40 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v3]
In-Reply-To: <rLCYanEPV0yIhf_y7ct8htF_Dup2aeVnqWGadUCoR5Y=.9e785193-23b9-41d4-9714-b182480cf2da@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
 <rLCYanEPV0yIhf_y7ct8htF_Dup2aeVnqWGadUCoR5Y=.9e785193-23b9-41d4-9714-b182480cf2da@github.com>
Message-ID: <IAR8WEbJ5KFhbGGuDJAljwFizq8CVI7Bn9KIwYvUfkw=.913cd0ca-7842-4022-9643-b2a82844a3fa@github.com>

On Tue, 8 Jul 2025 14:29:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
>> 
>> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Revert accidental
>  - Merge branch 'master' into JDK-8361520-stabilize-systemgc
>  - Do System.gc() once at start
>  - Revert accidental comment removal
>  - Fix

Now that each run is more stable, I wonder if it makes sense to reduce `@Fork(value=25`.

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26182#pullrequestreview-3000530658

From shade at openjdk.org  Wed Jul  9 08:30:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Jul 2025 08:30:42 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v3]
In-Reply-To: <IAR8WEbJ5KFhbGGuDJAljwFizq8CVI7Bn9KIwYvUfkw=.913cd0ca-7842-4022-9643-b2a82844a3fa@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
 <rLCYanEPV0yIhf_y7ct8htF_Dup2aeVnqWGadUCoR5Y=.9e785193-23b9-41d4-9714-b182480cf2da@github.com>
 <IAR8WEbJ5KFhbGGuDJAljwFizq8CVI7Bn9KIwYvUfkw=.913cd0ca-7842-4022-9643-b2a82844a3fa@github.com>
Message-ID: <Jxd88CcJHd9mwCt-e0oJ38TXdkWw1KhrRGis1owZxTA=.c904372c-c946-4cea-8bd9-5e8048e8af1f@github.com>

On Wed, 9 Jul 2025 08:18:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Now that each run is more stable, I wonder if it makes sense to reduce `@Fork(value=25`.

I tested it, it does not, we still want lots of samples.

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

PR Comment: https://git.openjdk.org/jdk/pull/26182#issuecomment-3051668171

From shade at openjdk.org  Wed Jul  9 08:59:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Jul 2025 08:59:46 GMT
Subject: RFR: 8361520: Stabilize SystemGC benchmarks [v3]
In-Reply-To: <rLCYanEPV0yIhf_y7ct8htF_Dup2aeVnqWGadUCoR5Y=.9e785193-23b9-41d4-9714-b182480cf2da@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
 <rLCYanEPV0yIhf_y7ct8htF_Dup2aeVnqWGadUCoR5Y=.9e785193-23b9-41d4-9714-b182480cf2da@github.com>
Message-ID: <hV-Qa_zvV_J6DM_8y0ZnrQjvCO_8COYo15ZvadC5C-Y=.24d02568-287f-4c34-8c83-ddd4099faafa@github.com>

On Tue, 8 Jul 2025 14:29:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
>> 
>> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Revert accidental
>  - Merge branch 'master' into JDK-8361520-stabilize-systemgc
>  - Do System.gc() once at start
>  - Revert accidental comment removal
>  - Fix

Thanks for reviews! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26182#issuecomment-3051765067

From shade at openjdk.org  Wed Jul  9 08:59:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Jul 2025 08:59:46 GMT
Subject: Integrated: 8361520: Stabilize SystemGC benchmarks
In-Reply-To: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
References: <MbanUS-pLud2ANJ0I-qY-bFnqX3ZgDNHlQYcVXZTw18=.7c7fe222-34b9-4f29-9b86-e0caa41d9ce7@github.com>
Message-ID: <u-ldy8crtHKSNZQqYd4ciyBn9k9_XgFIWUajG25aF9A=.33fd367c-5291-40df-bc03-14d8da2bec34@github.com>

On Tue, 8 Jul 2025 09:02:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this while working on a related bug ([JDK-8359960](https://bugs.openjdk.org/browse/JDK-8359960)):
> 
> First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, the benchmark is really, really noisy. Part of it is due to first iteration being noisy, but also we want more samples to shrink the estimated errors.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `gc.systemgc` benchmark runs

This pull request has now been integrated.

Changeset: a9bd1ad4
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9bd1ad40cb4e275d83b2e8b15e3c4be1551f7fc
Stats:     125 lines in 12 files changed: 125 ins; 0 del; 0 mod

8361520: Stabilize SystemGC benchmarks

Reviewed-by: tschatzl, ayang

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

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

From duke at openjdk.org  Wed Jul  9 10:28:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 9 Jul 2025 10:28:53 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <RzsVljkEciO5v59UGiFbhUSNlxNaflWisBIymEXbVnM=.07588a46-706e-45b2-9f04-c71989791f80@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

There?s a?missing ?n??in?the?**PR** and?**JBS** issue?titles:

-JDK-8361342: Sheandoah evacuation may assert on invalid mirror object after JDK-8340297
+JDK-8361342: Shenandoah evacuation may assert on invalid mirror object after JDK-8340297

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3052089153

From lucy at openjdk.org  Wed Jul  9 10:43:38 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 9 Jul 2025 10:43:38 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue
In-Reply-To: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
Message-ID: <1zTwwVrBU8QFVlK-UIlukZw32Lcv0q3WctXaKsIYG0o=.d8b8bd5f-e06e-4ba4-9361-21dbf504dafd@github.com>

On Tue, 8 Jul 2025 13:31:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test
> gc/z/TestMappedCacheHarvest.java
> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
> 
> 
>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
> young_to_old_ratio:27561965412.478878
> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
> `uint(young_workers * young_to_old_ratio)` .
> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

LGTM - as local remedy. 
I would feel better though if the root cause of the out-of-bounds value would be understood.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26186#pullrequestreview-3001015890

From mbaesken at openjdk.org  Wed Jul  9 10:59:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Jul 2025 10:59:38 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue
In-Reply-To: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
Message-ID: <2B2r6kemp0SBKoDrBJmBO6aGQifAb2apwh7VIkrCvAA=.e9a4b3b1-7408-4018-a94b-2202ae1015a7@github.com>

On Tue, 8 Jul 2025 13:31:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test
> gc/z/TestMappedCacheHarvest.java
> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
> 
> 
>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
> young_to_old_ratio:27561965412.478878
> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
> `uint(young_workers * young_to_old_ratio)` .
> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

calculate_young_to_old_worker_ratio  returns a  double and this can get (in theory) very large.
and the calculation part of this method

  const double old_vs_young_efficiency_ratio = current_old_bytes_freed_per_gc_time / current_young_bytes_freed_per_gc_time;
  return old_vs_young_efficiency_ratio;

can , depending on what has been freed, get also in practice very large; so it is not really a surprise that we see sometimes  large values.

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

PR Comment: https://git.openjdk.org/jdk/pull/26186#issuecomment-3052188932

From stuefe at openjdk.org  Wed Jul  9 11:43:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Jul 2025 11:43:43 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>
Message-ID: <iPlB8psDzfZwlOzhyjV5CNHuLotYG4duJzK-rVftC4I=.c78e1df7-942d-42f6-ba79-c4dbf9fb27a0@github.com>

On Tue, 8 Jul 2025 17:50:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The explanation and the changes make sense to me. Thank you!

Thanks for the review, @earthling-amzn !

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3052317728

From stuefe at openjdk.org  Wed Jul  9 11:43:42 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Jul 2025 11:43:42 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>
Message-ID: <cJXUX6NTxhOfamkXEpJrPdTDhp-MOiWM_aR5F-FtoN8=.ee61855f-985f-467e-acd5-1eb6ce855737@github.com>

On Tue, 8 Jul 2025 16:30:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Only looked at this briefly, but that sounds like what I did here: #21064 -- but forgot to complete it?
> 
> Yes, it looks like it is! The sequence of events you describe seems to also match [JDK-8340364](https://bugs.openjdk.org/browse/JDK-8340364), which I think we can close as duplicate, as I have not been able to convince even myself is a real bug, not just overzealous verification. So, what do you want to do? I can finish up #21064 and test it with your Metaspace assertion patches, if you want.

Thanks, let me just finish this, I need the closure after burning time on this non-bug :-)

Note that I did not fix up the use of the array mirror klass since I thought it should always be stable. We never redefine array classes. But then it does not hurt either.

I am also preparing a small improvement patch for print_obj, as per our discussion in https://github.com/openjdk/jdk/pull/26117 yesterday, and will put the printing of the mirror klasses there, too.

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3052316755

From ayang at openjdk.org  Wed Jul  9 12:20:49 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 12:20:49 GMT
Subject: RFR: 8361704: Parallel: Simplify logic condition in
 MutableNUMASpace::initialize
Message-ID: <pRnFYlWrd2OeDjlrE-4bYzJb9HPqh6LXhlLQHA2uXlU=.8739cebe-d563-42d5-bab9-8f8a5821baf9@github.com>

Trivial simplification via logical equivalence reduction.

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

Commit messages:
 - pgc-bool-trivial

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

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

From shade at openjdk.org  Wed Jul  9 15:18:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Jul 2025 15:18:41 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <cJXUX6NTxhOfamkXEpJrPdTDhp-MOiWM_aR5F-FtoN8=.ee61855f-985f-467e-acd5-1eb6ce855737@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>
 <cJXUX6NTxhOfamkXEpJrPdTDhp-MOiWM_aR5F-FtoN8=.ee61855f-985f-467e-acd5-1eb6ce855737@github.com>
Message-ID: <iQtBqK9MiV1lDHOgSU3LDqjiEkba1MHDakCt3VgyoC0=.fd09e93e-f11c-4b78-ae07-063fcfd2c783@github.com>

On Wed, 9 Jul 2025 11:41:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Thanks, let me just finish this, I need the closure after burning time on this non-bug :-)

Sure, OK. Please pick up most of the hunks from https://github.com/openjdk/jdk/pull/21064, including the array mirrors then? I don't see a need to write a full paragraph of text explaining why we need to check for forwarded objects. A simple sentence is enough, and the rest can go into the bug description.

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3053043840

From mdoerr at openjdk.org  Wed Jul  9 15:52:41 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 9 Jul 2025 15:52:41 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
Message-ID: <hlDU5LNfQpDuxMhil3r3PiRh1ycvqN9oB2iKw5POOk8=.af18be19-2fa3-4ad5-b75d-c625fa5f6ea7@github.com>

On Tue, 8 Jul 2025 15:03:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

Good finding! I think it looks good, but it should get reviewed by G1 experts.
The test doesn't always pass. I've seen this once:

[12.943s][info ][codecache] Triggering aggressive GC due to having only 49.991% free memory
[12.944s][trace][gc       ] C1 CompilerThread3: Try Collect Concurrently (CodeCache GC Aggressive): attempt 1
[12.984s][debug][gc       ] GC(22) Allocated 2 survivor 0 old percent total 6.67% (10%)
[12.984s][info ][gc       ] GC(22) Pause Young (Concurrent Start) (CodeCache GC Aggressive) 4M->2M(32M) 39.712ms
[12.984s][info ][gc       ] GC(23) Concurrent Mark Cycle
[12.984s][trace][gc       ] C1 CompilerThread3: Try Collect Concurrently (CodeCache GC Aggressive): wait
[13.040s][info ][codecache] Code cache critically low; use aggressive aging
[13.040s][info ][gc       ] GC(23) Pause Remark 3M->3M(32M) 6.383ms
[13.052s][info ][gc       ] GC(23) Pause Cleanup 3M->3M(32M) 0.078ms
[13.052s][info ][gc       ] GC(23) Concurrent Mark Cycle 67.851ms
[13.052s][trace][gc       ] C1 CompilerThread3: Try Collect Concurrently (CodeCache GC Aggressive): complete after wait
[13.056s][info ][codecache] Triggering aggressive GC due to having only 49.854% free memory
[13.056s][trace][gc       ] C1 CompilerThread2: Try Collect Concurrently (CodeCache GC Aggressive): attempt 1
[13.094s][debug][gc       ] GC(24) Allocated 2 survivor 1 old percent total 10.34% (10%)
[13.095s][info ][gc       ] GC(24) Pause Young (Concurrent Start) (CodeCache GC Aggressive) 3M->2M(32M) 38.594ms
[13.095s][trace][gc       ] C1 CompilerThread2: Try Collect Concurrently (CodeCache GC Aggressive): wait
[13.095s][info ][gc       ] GC(25) Concurrent Mark Cycle
[13.149s][info ][codecache] No code cache pressure; don't age code
[13.149s][info ][gc       ] GC(25) Pause Remark 3M->3M(32M) 11.108ms
[13.163s][info ][gc       ] GC(25) Pause Cleanup 3M->3M(32M) 0.072ms
[13.163s][info ][gc       ] GC(25) Concurrent Mark Cycle 68.023ms
[13.163s][trace][gc       ] C1 CompilerThread2: Try Collect Concurrently (CodeCache GC Aggressive): complete after wait
Compiled 180 classes
Compilation done, compiled 200 classes

STDERR:
java.lang.RuntimeException: Could not find a CodeCache GC Threshold GC after finishing the concurrent cycle: expected true, was false

Seems like there are several ways the VM can take.

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

PR Comment: https://git.openjdk.org/jdk/pull/26189#issuecomment-3053106193

From tschatzl at openjdk.org  Wed Jul  9 15:52:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 15:52:42 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <hlDU5LNfQpDuxMhil3r3PiRh1ycvqN9oB2iKw5POOk8=.af18be19-2fa3-4ad5-b75d-c625fa5f6ea7@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <hlDU5LNfQpDuxMhil3r3PiRh1ycvqN9oB2iKw5POOk8=.af18be19-2fa3-4ad5-b75d-c625fa5f6ea7@github.com>
Message-ID: <bLupgybC6fjXYg1T5hBiUi4chdbzKMpk6AVC8qXagfg=.daf54752-54a3-4ecb-9a2a-9bdae309bedb@github.com>

On Wed, 9 Jul 2025 15:33:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Good finding! I think it looks good, but it should get reviewed by G1 experts. The test doesn't always pass. I've seen this once:
> 
> ```
> [12.943s][info ][codecache] Triggering aggressive GC due to having only 49.991% free memory
> [12.944s][trace][gc       ] C1 CompilerThread3: Try Collect Concurrently (CodeCache GC Aggressive): attempt 1
> [12.984s][debug][gc       ] GC(22) Allocated 2 survivor 0 old percent total 6.67% (10%)
> [12.984s][info ][gc       ] GC(22) Pause Young (Concurrent Start) (CodeCache GC Aggressive) 4M->2M(32M) 39.712ms
> [12.984s][info ][gc       ] GC(23) Concurrent Mark Cycle
> [12.984s][trace][gc       ] C1 CompilerThread3: Try Collect Concurrently (CodeCache GC Aggressive): wait
> [13.040s][info ][codecache] Code cache critically low; use aggressive aging
> [13.040s][info ][gc       ] GC(23) Pause Remark 3M->3M(32M) 6.383ms
> [13.052s][info ][gc       ] GC(23) Pause Cleanup 3M->3M(32M) 0.078ms
> [13.052s][info ][gc       ] GC(23) Concurrent Mark Cycle 67.851ms
> [13.052s][trace][gc       ] C1 CompilerThread3: Try Collect Concurrently (CodeCache GC Aggressive): complete after wait
> [13.056s][info ][codecache] Triggering aggressive GC due to having only 49.854% free memory
> [13.056s][trace][gc       ] C1 CompilerThread2: Try Collect Concurrently (CodeCache GC Aggressive): attempt 1
> [13.094s][debug][gc       ] GC(24) Allocated 2 survivor 1 old percent total 10.34% (10%)
> [13.095s][info ][gc       ] GC(24) Pause Young (Concurrent Start) (CodeCache GC Aggressive) 3M->2M(32M) 38.594ms
> [13.095s][trace][gc       ] C1 CompilerThread2: Try Collect Concurrently (CodeCache GC Aggressive): wait
> [13.095s][info ][gc       ] GC(25) Concurrent Mark Cycle
> [13.149s][info ][codecache] No code cache pressure; don't age code
> [13.149s][info ][gc       ] GC(25) Pause Remark 3M->3M(32M) 11.108ms
> [13.163s][info ][gc       ] GC(25) Pause Cleanup 3M->3M(32M) 0.072ms
> [13.163s][info ][gc       ] GC(25) Concurrent Mark Cycle 68.023ms
> [13.163s][trace][gc       ] C1 CompilerThread2: Try Collect Concurrently (CodeCache GC Aggressive): complete after wait
> Compiled 180 classes
> Compilation done, compiled 200 classes
> 
> STDERR:
> java.lang.RuntimeException: Could not find a CodeCache GC Threshold GC after finishing the concurrent cycle: expected true, was false
> ```
> 
> Seems like there are several ways the VM can take.

This is a test bug - for some reason the compiler triggered "Code Cache Aggressive" instead of "Code Cache Threshold" gcs. The former are a more urgent version of the latter, so for that test this is fine.

The test only checks for the latter.

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

PR Comment: https://git.openjdk.org/jdk/pull/26189#issuecomment-3053152382

From shade at openjdk.org  Wed Jul  9 15:59:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Jul 2025 15:59:03 GMT
Subject: RFR: 8231269: CompileTask::is_unloaded is slow due to JNIHandles
 type checks [v22]
In-Reply-To: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
References: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
Message-ID: <t2g3pL61LGzT_9zvIc5hgo0B0eRVylwywBKHUGhDiU8=.c086fb74-cd8b-4cee-a15b-07bb87b317f1@github.com>

> [JDK-8163511](https://bugs.openjdk.org/browse/JDK-8163511) made the `CompileTask` improvement to avoid blocking class unloading if a relevant compile task is in queue. Current code does a sleight-of-hand to make sure the the `method*` in `CompileTask` are still valid before using them. Still a noble goal, so we keep trying to do this.
> 
> The code tries to switch weak JNI handle with a strong one when it wants to capture the holder to block unloading. Since we are reusing the same field, we have to do type checks like `JNIHandles::is_weak_global_handle(_method_holder)`. Unfortunately, that type-check goes all the way to `OopStorage` allocation code to verify the handle is really allocated in the relevant `OopStorage`. This takes internal `OopStorage` locks, and thus is slow.
> 
> This issue is clearly visible in Leyden, when there are lots of `CompileTask`-s in the queue, dumped by AOT code loader. It also does not help that `CompileTask::select_task` is effectively quadratic in number of methods in queue, so we end up calling `CompileTask::is_unloaded` very often.
> 
> It is possible to mitigate this issue by splitting the related fields into weak and strong ones. But as Kim mentions in the bug, we should not be using JNI handles here at all, and instead go directly for relevant `OopStorage`-s. This is what this PR does, among other things that should hopefully make the whole mechanics clearer.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `compiler/classUnloading`, 100x still passes; these tests are sensitive to bugs in this code
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge branch 'master' into JDK-8231269-compile-task-weaks
 - Merge branch 'master' into JDK-8231269-compile-task-weaks
 - Switch to mutable
 - Merge branch 'master' into JDK-8231269-compile-task-weaks
 - More touchups
 - Spin lock induces false sharing
 - Merge branch 'master' into JDK-8231269-compile-task-weaks
 - Merge branch 'master' into JDK-8231269-compile-task-weaks
 - Rename CompilerTask::is_unloaded back to avoid losing comment context
 - Simplify select_for_compilation
 - ... and 27 more: https://git.openjdk.org/jdk/compare/a41d3507...d5a8a27d

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

Changes: https://git.openjdk.org/jdk/pull/24018/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24018&range=21
  Stats: 430 lines in 13 files changed: 389 ins; 21 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24018.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24018/head:pull/24018

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

From kbarrett at openjdk.org  Wed Jul  9 17:36:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Jul 2025 17:36:41 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
Message-ID: <Y-iF6QeXEjR3T_fgnBF8nKbMQ2Hd5Fd-rJlmjLsHP4c=.101477bf-bebe-43ac-a3a2-37cfef779b9a@github.com>

On Tue, 8 Jul 2025 15:03:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1757:

> 1755:     } else if (!GCCause::is_user_requested_gc(cause) &&
> 1756:                // We can only skip CodeCache requested GCs if we are before marking.
> 1757:                (!GCCause::is_codecache_requested_gc(cause) || op.marking_in_progress()) ) {

Wouldn't this be a lot simpler like this:

} else if (GCCause::is_codecache_requested_gc(cause) && op.marking_in_progress()) {
  LOG_COLLECT_CONCURRENTLY_COMPLETE(cause, true);
  return true;
} else if (!GCCause::is_user_requested_gc(cause) && !GCCause::is_codecache_requested_gc(cause)) {
  ... unchanged old code ...
}

Of course, the codecache case needs some comments.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1783:

> 1781:           op.whitebox_attached() ||
> 1782:           (old_marking_started_before != old_marking_started_after)) {
> 1783:         LOG_COLLECT_CONCURRENTLY_COMPLETE(cause, true);

[github won't let me comment on lines in "User-requested GC" clause. This is
as close as I can get.]

We can now reach the "User-requested GC" clause with a CodeCache request,
which is not a user-request.  So the comments need updating in that clause to
account for that.

Also, I'm not sure the assert at the beginning of that clause is correct for a
CodeCache request. Similarly for the later assert after waiting for an
in-progress cycle to complete. At least, the comments are suggestive of there
being problems with those asserts if a CodeCache request gets there.

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

PR Review: https://git.openjdk.org/jdk/pull/26189#pullrequestreview-3002443465
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2195601079
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2195602496

From wkemper at openjdk.org  Wed Jul  9 17:57:14 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Jul 2025 17:57:14 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
Message-ID: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>

Shenandoah has `product only` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.

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

Commit messages:
 - Convert evac tracking back into non-product feature
 - Re-enable evac tracker, account for young/old/promotions

Changes: https://git.openjdk.org/jdk/pull/26222/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26222&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361726
  Stats: 149 lines in 9 files changed: 79 ins; 26 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/26222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26222/head:pull/26222

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

From kbarrett at openjdk.org  Wed Jul  9 19:15:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Jul 2025 19:15:44 GMT
Subject: RFR: 8231269: CompileTask::is_unloaded is slow due to JNIHandles
 type checks [v19]
In-Reply-To: <Me9cXhDoNROeTJ58iW7fc_Jyyid6xvVUvyMEC7KXZZE=.b2afd679-3446-4941-908d-364b5991b366@github.com>
References: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
 <WKBGCNSnxTtI7m_goGB13s2hhnCp2lupjBh0W-5U9Nc=.64278552-ca67-46f8-a80a-23a838c65000@github.com>
 <Yb2vGecKA1Ywpx0uxIgvZg8dvHsCWArjXwIq75uPJT8=.a5e4141b-58fa-4008-ae69-5a3368713361@github.com>
 <Me9cXhDoNROeTJ58iW7fc_Jyyid6xvVUvyMEC7KXZZE=.b2afd679-3446-4941-908d-364b5991b366@github.com>
Message-ID: <I8CZpNwh_Gs2C9L3sNMVd2R7mdI0LXdLRNu6IzJQgeA=.fef7d2c1-d734-4e3a-b3e8-19b85db12d7d@github.com>

On Mon, 26 May 2025 18:58:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Not sure what our opinion is w.r.t. `mutable`, but how do we feel about typing the spin lock as `mutable` and keep `is_safe()` and `method*()` const.
> 
> I like this a lot! Dropping `const` just to satisfy spin lock (an implementation detail) felt really awkward. New version uses `mutable`.

Just a drive-by reply.  `mutable` is a C++98 (and before, I think) feature, with many uses in HotSpot.  Using it here
seems fine to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/24018#issuecomment-3053728810

From kbarrett at openjdk.org  Wed Jul  9 19:29:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Jul 2025 19:29:45 GMT
Subject: RFR: 8231269: CompileTask::is_unloaded is slow due to JNIHandles
 type checks [v22]
In-Reply-To: <t2g3pL61LGzT_9zvIc5hgo0B0eRVylwywBKHUGhDiU8=.c086fb74-cd8b-4cee-a15b-07bb87b317f1@github.com>
References: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
 <t2g3pL61LGzT_9zvIc5hgo0B0eRVylwywBKHUGhDiU8=.c086fb74-cd8b-4cee-a15b-07bb87b317f1@github.com>
Message-ID: <jLG_W24VgnhfFFnL64mhDcL0ygvxe_N6YiybJgna3-Q=.21eab569-16e4-4abf-a6e1-eded4bc9f0a6@github.com>

On Wed, 9 Jul 2025 15:59:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8163511](https://bugs.openjdk.org/browse/JDK-8163511) made the `CompileTask` improvement to avoid blocking class unloading if a relevant compile task is in queue. Current code does a sleight-of-hand to make sure the the `method*` in `CompileTask` are still valid before using them. Still a noble goal, so we keep trying to do this.
>> 
>> The code tries to switch weak JNI handle with a strong one when it wants to capture the holder to block unloading. Since we are reusing the same field, we have to do type checks like `JNIHandles::is_weak_global_handle(_method_holder)`. Unfortunately, that type-check goes all the way to `OopStorage` allocation code to verify the handle is really allocated in the relevant `OopStorage`. This takes internal `OopStorage` locks, and thus is slow.
>> 
>> This issue is clearly visible in Leyden, when there are lots of `CompileTask`-s in the queue, dumped by AOT code loader. It also does not help that `CompileTask::select_task` is effectively quadratic in number of methods in queue, so we end up calling `CompileTask::is_unloaded` very often.
>> 
>> It is possible to mitigate this issue by splitting the related fields into weak and strong ones. But as Kim mentions in the bug, we should not be using JNI handles here at all, and instead go directly for relevant `OopStorage`-s. This is what this PR does, among other things that should hopefully make the whole mechanics clearer.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `compiler/classUnloading`, 100x still passes; these tests are sensitive to bugs in this code
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>  - Switch to mutable
>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>  - More touchups
>  - Spin lock induces false sharing
>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>  - Rename CompilerTask::is_unloaded back to avoid losing comment context
>  - Simplify select_for_compilation
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/a41d3507...d5a8a27d

src/hotspot/share/oops/unloadableMethodHandle.hpp line 81:

> 79:   friend class VMStructs;
> 80: private:
> 81:   enum State {

Not really a review, just a drive-by comment.
I think the only argument against using an enum class here is the lack of C++20's "using enums"
feature: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html
Personally I'd prefer to just make it an enum class and scope the references. YMMV.

Also, someday we should try to come to some consensus about the naming of constants.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24018#discussion_r2195817179

From kbarrett at openjdk.org  Wed Jul  9 19:32:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Jul 2025 19:32:45 GMT
Subject: RFR: 8231269: CompileTask::is_unloaded is slow due to JNIHandles
 type checks [v11]
In-Reply-To: <eBZnxaJtNHzwepKjqqGG-9yj2gVC7VF7yvIc82jg5FA=.e63e8927-a257-4134-9ce1-74f56a4922a5@github.com>
References: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
 <OE4M0qGYK_Cz76K0Vqh50Mi_JwafFsA4VJ4mxknI7ec=.f4f4806b-9d42-42e6-8f4e-2e5ea9473f6b@github.com>
 <eBZnxaJtNHzwepKjqqGG-9yj2gVC7VF7yvIc82jg5FA=.e63e8927-a257-4134-9ce1-74f56a4922a5@github.com>
Message-ID: <O7YcCDzY-nBR1S_rwbelK9D_RKRFU8ld0MKeZ64FQlk=.0d66f688-275b-467f-b26e-416d3e42fe9a@github.com>

On Wed, 7 May 2025 20:31:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a cleaner way to do this. I believe it's what we discussed with Kim. He can confirm.

Yes, I think this looks like the sort of thing I had in mind when we were discussing it back whenever that was.

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

PR Comment: https://git.openjdk.org/jdk/pull/24018#issuecomment-3053768403

From mbeckwit at openjdk.org  Wed Jul  9 20:15:29 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Wed, 9 Jul 2025 20:15:29 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
Message-ID: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>

**Implements:** https://bugs.openjdk.org/browse/JDK-8357445

Implement time-based heap uncommit for G1 during idle periods.

Key changes:
- Added G1HeapEvaluationTask for periodic heap evaluation
- Switch from G1ServiceTask to PeriodicTask for virtual thread support
- Implemented time-based heap sizing policy with configurable uncommit delay
- Added region activity tracking with last access timestamps
- Integrated VM_G1ShrinkHeap operation for safe heap shrinking
- Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
- Added 'sizing' log tag for heap sizing operations

Comprehensive Test Coverage:
- Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
- Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
- Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
- Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations

This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

Commit messages:
 - Fix trailing whitespace errors
 - JDK-8357445: G1: Time-Based Heap Uncommit During Idle Periods

Changes: https://git.openjdk.org/jdk/pull/26207/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26207&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357445
  Stats: 6178 lines in 21 files changed: 1276 ins; 4892 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26207/head:pull/26207

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

From wkemper at openjdk.org  Wed Jul  9 21:12:16 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Jul 2025 21:12:16 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
Message-ID: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>

Clean backport. Fixes bad pointer in assert.

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

Commit messages:
 - Backport 1de2acea77da57fd44b214332a73cc6621806e4d

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

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

From mbeckwit at openjdk.org  Thu Jul 10 04:31:07 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 04:31:07 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <twAWth8zQ8NAgXpKWm3JC7rQD_o5D8xPNbMgsPslMvM=.56a54075-31ab-4bbf-a0b9-1b3bb998a1a2@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for virtual thread support
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

  Fix merge conflict corruption and restore time-based heap sizing changes
  
  - Restore g1CollectedHeap.cpp, g1CollectedHeap.hpp, g1HeapSizingPolicy.cpp from corrupted single-line format
  - Fix character encoding issue in g1HeapSizingPolicy.hpp (multiplication symbol)
  - All time-based heap sizing features restored and functional
  - Files are now in proper multi-line format and compilable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/a0bcdd58..650870a8

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

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

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

From mbeckwit at openjdk.org  Thu Jul 10 06:29:07 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 06:29:07 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v3]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <jQjF13fT0WWNDhBfnS_YhriEQbJmosaLXzvoUlLGRpM=.bb14bde9-7301-4970-b6c9-b72f7d6b31ed@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for virtual thread support
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

  Fix merge conflict corruption and restore time-based heap sizing changes
  
  - Restore g1CollectedHeap.cpp, g1CollectedHeap.hpp, g1HeapSizingPolicy.cpp from corrupted single-line format
  - Fix character encoding issue in g1HeapSizingPolicy.hpp (multiplication symbol)
  - All time-based heap sizing features restored and functional
  - Files are now in proper multi-line format and compilable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/650870a8..fc815905

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

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

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

From stuefe at openjdk.org  Thu Jul 10 06:32:29 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 10 Jul 2025 06:32:29 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297 [v2]
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

Thomas Stuefe 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:

 - Alekseys additions
 - Also check array klass
 - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
 - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
 - also fix ShenandoahVerifier
 - start

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26187/files
  - new: https://git.openjdk.org/jdk/pull/26187/files/3d07a9d9..c33cf248

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

  Stats: 982 lines in 56 files changed: 372 ins; 355 del; 255 mod
  Patch: https://git.openjdk.org/jdk/pull/26187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26187/head:pull/26187

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

From stuefe at openjdk.org  Thu Jul 10 06:32:29 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 10 Jul 2025 06:32:29 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <iQtBqK9MiV1lDHOgSU3LDqjiEkba1MHDakCt3VgyoC0=.fd09e93e-f11c-4b78-ae07-063fcfd2c783@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>
 <cJXUX6NTxhOfamkXEpJrPdTDhp-MOiWM_aR5F-FtoN8=.ee61855f-985f-467e-acd5-1eb6ce855737@github.com>
 <iQtBqK9MiV1lDHOgSU3LDqjiEkba1MHDakCt3VgyoC0=.fd09e93e-f11c-4b78-ae07-063fcfd2c783@github.com>
Message-ID: <is_m4xMmR038cvdGWkt7SbQE0B6EWnYLdl63i1YqjYs=.2e8fd17f-40de-4942-9b50-b67c6f241658@github.com>

On Wed, 9 Jul 2025 15:16:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> > Only looked at this briefly, but that sounds like what I did here: #21064 -- but forgot to complete it?
>>> 
>>> Yes, it looks like it is! The sequence of events you describe seems to also match [JDK-8340364](https://bugs.openjdk.org/browse/JDK-8340364), which I think we can close as duplicate, as I have not been able to convince even myself is a real bug, not just overzealous verification. So, what do you want to do? I can finish up #21064 and test it with your Metaspace assertion patches, if you want.
>> 
>> Thanks, let me just finish this, I need the closure after burning time on this non-bug :-)
>> 
>> Note that I did not fix up the use of the array mirror klass since I thought it should always be stable. We never redefine array classes. But then it does not hurt either.
>> 
>> I am also preparing a small improvement patch for print_obj, as per our discussion in https://github.com/openjdk/jdk/pull/26117 yesterday, and will put the printing of the mirror klasses there, too.
>
>> Thanks, let me just finish this, I need the closure after burning time on this non-bug :-)
> 
> Sure, OK. Please pick up most of the hunks from https://github.com/openjdk/jdk/pull/21064, including the array mirrors then? I don't see a need to write a full paragraph of text explaining why we need to check for forwarded objects. A simple sentence is enough, and the rest can go into the bug description.

@shipilev ok done

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3055805609

From mbaesken at openjdk.org  Thu Jul 10 07:15:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Jul 2025 07:15:42 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue
In-Reply-To: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
Message-ID: <KbNf7PNszlW8jfaygFB7BGMPTnwhSzefuhVjeKoyjCc=.219cf9ec-cd24-4aa2-bc04-88479567746f@github.com>

On Tue, 8 Jul 2025 13:31:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test
> gc/z/TestMappedCacheHarvest.java
> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
> 
> 
>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
> young_to_old_ratio:27561965412.478878
> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
> `uint(young_workers * young_to_old_ratio)` .
> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

Thanks for the review Lucy !
May I get a second review ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26186#issuecomment-3055992949

From tschatzl at openjdk.org  Thu Jul 10 07:17:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Jul 2025 07:17:42 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <Y-iF6QeXEjR3T_fgnBF8nKbMQ2Hd5Fd-rJlmjLsHP4c=.101477bf-bebe-43ac-a3a2-37cfef779b9a@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <Y-iF6QeXEjR3T_fgnBF8nKbMQ2Hd5Fd-rJlmjLsHP4c=.101477bf-bebe-43ac-a3a2-37cfef779b9a@github.com>
Message-ID: <42Bmn_G2-BDwMY8wipUHxYMF6DerOPA3U97CbRja_NY=.c55584b7-9224-481e-9c12-ed0aac414ca5@github.com>

On Wed, 9 Jul 2025 17:32:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1757:
> 
>> 1755:     } else if (!GCCause::is_user_requested_gc(cause) &&
>> 1756:                // We can only skip CodeCache requested GCs if we are before marking.
>> 1757:                (!GCCause::is_codecache_requested_gc(cause) || op.marking_in_progress()) ) {
> 
> Wouldn't this be a lot simpler like this:
> 
> } else if (GCCause::is_codecache_requested_gc(cause) && op.marking_in_progress()) {
>   LOG_COLLECT_CONCURRENTLY_COMPLETE(cause, true);
>   return true;
> } else if (!GCCause::is_user_requested_gc(cause) && !GCCause::is_codecache_requested_gc(cause)) {
>   ... unchanged old code ...
> }
> 
> Of course, the codecache case needs some comments.

That's much nicer, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2196818701

From mbeckwit at openjdk.org  Thu Jul 10 07:33:33 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 07:33:33 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <wlwSmc9NeegMOd2F8F5eMgkHCO-QWnwCb_7MM7SS12g=.5131c59d-9eaf-4771-b7bf-8f4df60416b3@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for virtual thread support
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

 - Normalize G1 C++ sources as text (LF eol)
 - Normalize C/C++ sources as text with LF eol

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/fc815905..d096e624

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

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

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

From mbeckwit at openjdk.org  Thu Jul 10 07:53:33 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 07:53:33 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v5]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <8pZBz9567s3Yrf_AgBRmQTb0jvXnIgC8J8g4en3EoCQ=.371eb710-e04c-4c23-ab59-d37fd5ae177f@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for virtual thread support
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

  JDK-8357445: Force GitHub to recognize G1 HotSpot files as text (temporary comment)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/d096e624..9e623d1b

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

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

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

From shade at openjdk.org  Thu Jul 10 08:15:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Jul 2025 08:15:44 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297 [v2]
In-Reply-To: <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
Message-ID: <39tOcsPGG2QXldhRafPyx1pz-NZzGW97AJXbO2aIf1A=.19b3120f-0290-47a6-8bf3-66f5669e6d13@github.com>

On Thu, 10 Jul 2025 06:32:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
>> 
>> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
>> 
>> For details about this issue, please see the Jira description and comment. The short version is:
>> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
>> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
>> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
>> 
>> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
>> 
>> Therefore I just changed the assertions.
>> 
>> But I would like to hear other people's opinion on this.
>> 
>> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.
>
> Thomas Stuefe 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:
> 
>  - Alekseys additions
>  - Also check array klass
>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>  - also fix ShenandoahVerifier
>  - start

Looks fine to me!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26187#pullrequestreview-3004477678

From tschatzl at openjdk.org  Thu Jul 10 08:17:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Jul 2025 08:17:41 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <Y-iF6QeXEjR3T_fgnBF8nKbMQ2Hd5Fd-rJlmjLsHP4c=.101477bf-bebe-43ac-a3a2-37cfef779b9a@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <Y-iF6QeXEjR3T_fgnBF8nKbMQ2Hd5Fd-rJlmjLsHP4c=.101477bf-bebe-43ac-a3a2-37cfef779b9a@github.com>
Message-ID: <ljB6TVslf0zYU7whxkwTEHvCvpo6Yf5A-AFXkPaSU7w=.511835ba-1993-456d-b2fb-21d19620fe76@github.com>

On Wed, 9 Jul 2025 17:33:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1783:
> 
>> 1781:           op.whitebox_attached() ||
>> 1782:           (old_marking_started_before != old_marking_started_after)) {
>> 1783:         LOG_COLLECT_CONCURRENTLY_COMPLETE(cause, true);
> 
> [github won't let me comment on lines in "User-requested GC" clause. This is
> as close as I can get.]
> 
> We can now reach the "User-requested GC" clause with a CodeCache request,
> which is not a user-request.  So the comments need updating in that clause to
> account for that.
> 
> Also, I'm not sure the assert at the beginning of that clause is correct for a
> CodeCache request. Similarly for the later assert after waiting for an
> in-progress cycle to complete. At least, the comments are suggestive of there
> being problems with those asserts if a CodeCache request gets there.

The test incidentally works because of whitebox being active. Otherwise the asserts would fail as you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2196948434

From mbeckwit at openjdk.org  Thu Jul 10 08:26:39 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 08:26:39 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v6]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <mdxuElAZtaLQWBICLEc6u-2Sx16eU-1HFEL_hXN2goU=.55c7bff3-d6f9-46b3-a84a-2169a20956c1@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for virtual thread support
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

  Reencode G1 C++ files as text (LF endings)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/9e623d1b..76f9ce19

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

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

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

From stuefe at openjdk.org  Thu Jul 10 08:40:39 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 10 Jul 2025 08:40:39 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>
Message-ID: <CCVnBo9RZcdBSWjuFkcsLvHOPueCZ7XQzozEpjJ0tJ8=.8ef77c4a-06d2-4023-bb4c-bb0c6f3bba66@github.com>

On Tue, 8 Jul 2025 17:50:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
>> 
>> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
>> 
>> For details about this issue, please see the Jira description and comment. The short version is:
>> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
>> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
>> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
>> 
>> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
>> 
>> Therefore I just changed the assertions.
>> 
>> But I would like to hear other people's opinion on this.
>> 
>> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.
>
> The explanation and the changes make sense to me. Thank you!

Thanks Aleksey! @earthling-amzn are you happy with this version, too?

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3056345044

From tschatzl at openjdk.org  Thu Jul 10 08:50:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Jul 2025 08:50:38 GMT
Subject: RFR: 8361704: Parallel: Simplify logic condition in
 MutableNUMASpace::initialize
In-Reply-To: <pRnFYlWrd2OeDjlrE-4bYzJb9HPqh6LXhlLQHA2uXlU=.8739cebe-d563-42d5-bab9-8f8a5821baf9@github.com>
References: <pRnFYlWrd2OeDjlrE-4bYzJb9HPqh6LXhlLQHA2uXlU=.8739cebe-d563-42d5-bab9-8f8a5821baf9@github.com>
Message-ID: <mMhj-3H08kJgzA8JQgiumRjdArxTts3ww9Vc6V_UVFg=.61f38069-709d-4744-90d9-742c423c85c2@github.com>

On Wed, 9 Jul 2025 12:14:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial simplification via logical equivalence reduction.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26218#pullrequestreview-3004600499

From mbeckwit at openjdk.org  Thu Jul 10 09:08:13 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 09:08:13 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v7]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <x9FCZjjzuv_WdZqpIebsG8SpfUfeuonHNnw1spVtmJI=.f32c995c-f973-4081-8abc-070c1db7dbfb@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for virtual thread support
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

  Normalize g1CollectedHeap.cpp as text (LF endings)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/76f9ce19..ca30e3da

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

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

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

From ayang at openjdk.org  Thu Jul 10 09:23:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 10 Jul 2025 09:23:43 GMT
Subject: Integrated: 8361704: Parallel: Simplify logic condition in
 MutableNUMASpace::initialize
In-Reply-To: <pRnFYlWrd2OeDjlrE-4bYzJb9HPqh6LXhlLQHA2uXlU=.8739cebe-d563-42d5-bab9-8f8a5821baf9@github.com>
References: <pRnFYlWrd2OeDjlrE-4bYzJb9HPqh6LXhlLQHA2uXlU=.8739cebe-d563-42d5-bab9-8f8a5821baf9@github.com>
Message-ID: <THiZpEx1gRNCRswHViTw3Kc9Rjkn42Yd8GBttsUFMXo=.4678c165-f605-4a2b-b473-2d8e12fed4e3@github.com>

On Wed, 9 Jul 2025 12:14:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial simplification via logical equivalence reduction.

This pull request has now been integrated.

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

8361704: Parallel: Simplify logic condition in MutableNUMASpace::initialize

Reviewed-by: tschatzl

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

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

From ayang at openjdk.org  Thu Jul 10 09:23:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 10 Jul 2025 09:23:43 GMT
Subject: RFR: 8361704: Parallel: Simplify logic condition in
 MutableNUMASpace::initialize
In-Reply-To: <pRnFYlWrd2OeDjlrE-4bYzJb9HPqh6LXhlLQHA2uXlU=.8739cebe-d563-42d5-bab9-8f8a5821baf9@github.com>
References: <pRnFYlWrd2OeDjlrE-4bYzJb9HPqh6LXhlLQHA2uXlU=.8739cebe-d563-42d5-bab9-8f8a5821baf9@github.com>
Message-ID: <R28sXxmx7pZivmlUeez4F99WBez4-I_4yYs6WcrrHVU=.56499714-545b-4d95-8ccc-1221cfe9811b@github.com>

On Wed, 9 Jul 2025 12:14:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial simplification via logical equivalence reduction.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26218#issuecomment-3056499545

From mbeckwit at openjdk.org  Thu Jul 10 10:20:49 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 10:20:49 GMT
Subject: Withdrawn: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <p3fyh1A1JfU-E_UipjpLlV1if9tcpHWKglrn2ORZn0I=.e6833c94-7e2b-45dc-9e4e-04f4b1114540@github.com>

On Wed, 9 Jul 2025 02:29:10 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for virtual thread support
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

This pull request has been closed without being integrated.

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

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

From mbeckwit at openjdk.org  Thu Jul 10 10:21:06 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 10:21:06 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
Message-ID: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>

**Implements:** https://bugs.openjdk.org/browse/JDK-8357445

Implement time-based heap uncommit for G1 during idle periods.

Key changes:
- Added G1HeapEvaluationTask for periodic heap evaluation
- Switch from G1ServiceTask to PeriodicTask for virtual thread support
- Implemented time-based heap sizing policy with configurable uncommit delay
- Added region activity tracking with last access timestamps
- Integrated VM_G1ShrinkHeap operation for safe heap shrinking
- Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
- Added 'sizing' log tag for heap sizing operations

Comprehensive Test Coverage:
- Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
- Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
- Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
- Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations

This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

Commit messages:
 - JDK-8357445: G1: Time-Based Heap Uncommit During Idle Periods

Changes: https://git.openjdk.org/jdk/pull/26240/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357445
  Stats: 1496 lines in 21 files changed: 1487 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240

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

From shade at openjdk.org  Thu Jul 10 13:02:07 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Jul 2025 13:02:07 GMT
Subject: RFR: 8231269: CompileTask::is_unloaded is slow due to JNIHandles
 type checks [v23]
In-Reply-To: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
References: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
Message-ID: <atwp-vIt-Soat1HWpbQiw2nrTP1W4ShgoX_gYcIIfs0=.316a11ec-bc2f-4c46-b330-815d7d7122d2@github.com>

> [JDK-8163511](https://bugs.openjdk.org/browse/JDK-8163511) made the `CompileTask` improvement to avoid blocking class unloading if a relevant compile task is in queue. Current code does a sleight-of-hand to make sure the the `method*` in `CompileTask` are still valid before using them. Still a noble goal, so we keep trying to do this.
> 
> The code tries to switch weak JNI handle with a strong one when it wants to capture the holder to block unloading. Since we are reusing the same field, we have to do type checks like `JNIHandles::is_weak_global_handle(_method_holder)`. Unfortunately, that type-check goes all the way to `OopStorage` allocation code to verify the handle is really allocated in the relevant `OopStorage`. This takes internal `OopStorage` locks, and thus is slow.
> 
> This issue is clearly visible in Leyden, when there are lots of `CompileTask`-s in the queue, dumped by AOT code loader. It also does not help that `CompileTask::select_task` is effectively quadratic in number of methods in queue, so we end up calling `CompileTask::is_unloaded` very often.
> 
> It is possible to mitigate this issue by splitting the related fields into weak and strong ones. But as Kim mentions in the bug, we should not be using JNI handles here at all, and instead go directly for relevant `OopStorage`-s. This is what this PR does, among other things that should hopefully make the whole mechanics clearer.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `compiler/classUnloading`, 100x still passes; these tests are sensitive to bugs in this code
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with six additional commits since the last revision:

 - Docs touchup
 - Use enum class
 - Further simplify the API
 - Tune up for release builds
 - Move release() to destructor
 - Deal with things without spinlocks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24018/files
  - new: https://git.openjdk.org/jdk/pull/24018/files/d5a8a27d..b27c0633

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24018&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24018&range=21-22

  Stats: 162 lines in 3 files changed: 35 ins; 94 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/24018.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24018/head:pull/24018

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

From shade at openjdk.org  Thu Jul 10 13:02:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Jul 2025 13:02:09 GMT
Subject: RFR: 8231269: CompileTask::is_unloaded is slow due to JNIHandles
 type checks [v22]
In-Reply-To: <jLG_W24VgnhfFFnL64mhDcL0ygvxe_N6YiybJgna3-Q=.21eab569-16e4-4abf-a6e1-eded4bc9f0a6@github.com>
References: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
 <t2g3pL61LGzT_9zvIc5hgo0B0eRVylwywBKHUGhDiU8=.c086fb74-cd8b-4cee-a15b-07bb87b317f1@github.com>
 <jLG_W24VgnhfFFnL64mhDcL0ygvxe_N6YiybJgna3-Q=.21eab569-16e4-4abf-a6e1-eded4bc9f0a6@github.com>
Message-ID: <u24Xxd9JxrVj1kbDnZFDlxraS7hHec5zIUTSPmCB5FM=.c267a7ad-5fcd-497c-b557-2c5e7e5ef40c@github.com>

On Wed, 9 Jul 2025 19:26:41 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>>  - Switch to mutable
>>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>>  - More touchups
>>  - Spin lock induces false sharing
>>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>>  - Rename CompilerTask::is_unloaded back to avoid losing comment context
>>  - Simplify select_for_compilation
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/a41d3507...d5a8a27d
>
> src/hotspot/share/oops/unloadableMethodHandle.hpp line 81:
> 
>> 79:   friend class VMStructs;
>> 80: private:
>> 81:   enum State {
> 
> Not really a review, just a drive-by comment.
> I think the only argument against using an enum class here is the lack of C++20's "using enums"
> feature: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html
> Personally I'd prefer to just make it an enum class and scope the references. YMMV.
> 
> Also, someday we should try to come to some consensus about the naming of constants.

I don't mind converting this to enum class, done in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24018#discussion_r2197669086

From tschatzl at openjdk.org  Thu Jul 10 13:05:30 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Jul 2025 13:05:30 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v2]
In-Reply-To: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
Message-ID: <WjBzjdTZLh9-XBbAgWJL7FmqX_OsrEDKOBD6cqRYTVg=.b9b95d6b-dffe-4375-95a5-2599f5685080@github.com>

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

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

  * kbarret review:
    - restructure code in `try_collect_concurrently`
    - fix asserts - they only worked in the test because of whitebox being active
    - fix comments
  * threalmdoerr review:
    - fix test to be more lenient

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26189/files
  - new: https://git.openjdk.org/jdk/pull/26189/files/348a7896..36b023fb

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

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

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

From kcr at openjdk.org  Thu Jul 10 15:44:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 15:44:39 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <gb9wpfBvaQAxxdrrQ_6hBUyS3yAVNHuEBOrdJvXJmWo=.6b34beb7-e654-469f-b472-0b801dc667d7@github.com>

On Wed, 9 Jul 2025 21:06:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes bad pointer in assert.

If the priority of this bug (I see that the issue type is Task, which seems wrong) is correct, then this doesn't meet the criteria for backporting to JDK 25 during RDP1. See [JEP 3](https://openjdk.org/jeps/3).

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3057987411

From wkemper at openjdk.org  Thu Jul 10 16:04:52 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 16:04:52 GMT
Subject: [jdk25] RFR: 8357976: GenShen crash in swap_card_tables: Should be
 clean
Message-ID: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>

Clean backport. Fixes correctness issue in Shenandoah.

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

Commit messages:
 - Backport 382f870cd53d69dfc1d2b96150aa2c026e47f642

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

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

From wkemper at openjdk.org  Thu Jul 10 16:09:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 16:09:39 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <6v1Wq3K1UHTzNkXk43LvNF2w8QJsAPfjGoy0gdxSWCI=.d490d12d-9322-4e5b-b860-80369b3bd7cb@github.com>

On Wed, 9 Jul 2025 21:06:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes bad pointer in assert.

Yes, the ticket should have been marked a bug, thank you for fixing that. This change to the assert really should have been made with the same commit where we fixed an issue it uncovered (https://github.com/openjdk/jdk/pull/26246). We can leave the assertion change out, but it's also low risk (only affects Shenandoah debug builds).

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3058074838

From kcr at openjdk.org  Thu Jul 10 16:21:38 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 16:21:38 GMT
Subject: [jdk25] RFR: 8357976: GenShen crash in swap_card_tables: Should be
 clean
In-Reply-To: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
References: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
Message-ID: <JrWkIpq1v10HGiFMqQmfY44MI9BMyNignl6HVx3qZhw=.2d48d533-66e9-47f2-a2b3-d3a52526141b@github.com>

On Thu, 10 Jul 2025 15:59:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes correctness issue in Shenandoah.

If this is objectively a P3, then you could raise the priority. Otherwise, maybe consider backporting it to jdk25u?

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

PR Comment: https://git.openjdk.org/jdk/pull/26246#issuecomment-3058110001

From kcr at openjdk.org  Thu Jul 10 16:25:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 16:25:37 GMT
Subject: [jdk25] RFR: 8357976: GenShen crash in swap_card_tables: Should be
 clean
In-Reply-To: <JrWkIpq1v10HGiFMqQmfY44MI9BMyNignl6HVx3qZhw=.2d48d533-66e9-47f2-a2b3-d3a52526141b@github.com>
References: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
 <JrWkIpq1v10HGiFMqQmfY44MI9BMyNignl6HVx3qZhw=.2d48d533-66e9-47f2-a2b3-d3a52526141b@github.com>
Message-ID: <ZG1pSBt9wF3qeJhhWkl16iURmLAhItvJKnOVWrITwAA=.b01473b2-98e9-4ac5-97e1-41c9efe0090a@github.com>

On Thu, 10 Jul 2025 16:19:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> If this is objectively a P3, then you could raise the priority. Otherwise, maybe consider backporting it to jdk25u?

This comment was meant for PR #26228 -- sorry for the confusion.

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

PR Comment: https://git.openjdk.org/jdk/pull/26246#issuecomment-3058119789

From kcr at openjdk.org  Thu Jul 10 16:26:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 16:26:39 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <Hr8O3csiQCBloebGSa4NrUByhXY5Zc56JAEhbn3Q6lc=.23051a15-4a35-4199-96d0-a47d4f60c0c3@github.com>

On Wed, 9 Jul 2025 21:06:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes bad pointer in assert.

If this is objectively a P3, then you could raise the priority. Otherwise, maybe consider backporting it to jdk25u?

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3058118682

From kcr at openjdk.org  Thu Jul 10 16:26:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 16:26:40 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Hr8O3csiQCBloebGSa4NrUByhXY5Zc56JAEhbn3Q6lc=.23051a15-4a35-4199-96d0-a47d4f60c0c3@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
 <Hr8O3csiQCBloebGSa4NrUByhXY5Zc56JAEhbn3Q6lc=.23051a15-4a35-4199-96d0-a47d4f60c0c3@github.com>
Message-ID: <vn4fp0UEyTI0cMcBMgAOqmemNtJHkq8tF-g_PaI7WQI=.e870546d-a5f5-4840-8513-5e9c72864191@github.com>

On Thu, 10 Jul 2025 16:22:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> If this is objectively a P3, then you could raise the priority

Since, as you pointed out, this is a follow-on to the other fix, raising the priority seems OK to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3058125462

From shade at openjdk.org  Thu Jul 10 16:52:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Jul 2025 16:52:42 GMT
Subject: [jdk25] RFR: 8357976: GenShen crash in swap_card_tables: Should be
 clean
In-Reply-To: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
References: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
Message-ID: <AdqMf0PNZajoJrzP7ZMnau8IUXYU4NmAiuYNcpk4XSw=.a1e3637f-5da2-45cd-ac29-cdbdb9643b7e@github.com>

On Thu, 10 Jul 2025 15:59:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes correctness issue in Shenandoah.

Looks fine for JDK 25.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26246#pullrequestreview-3006542106

From shade at openjdk.org  Thu Jul 10 16:54:37 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Jul 2025 16:54:37 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <0Ex2dRNMWXsjkUvT5IK8g1dFolaby9JV8zCrAKRmf8Q=.f1312480-39bf-436d-b2e4-b1c7a0905b21@github.com>

On Wed, 9 Jul 2025 21:06:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes bad pointer in assert.

There are test failures, I assume they are fixed by https://github.com/openjdk/jdk/pull/26246? Integrate that one first and confirm there are no failures then? (I think you can technically update the `openjdk-bots:backport-earthling-amzn-1de2acea-jdk25` branch, since you probably are a collaborator on that repo, but I have never actually tried.)

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3058227580

From mbeckwit at openjdk.org  Thu Jul 10 18:09:17 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 18:09:17 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
Message-ID: <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for virtual thread support
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

  Normalize encoding and line endings for G1 GC time-based tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26240/files
  - new: https://git.openjdk.org/jdk/pull/26240/files/70531f8e..70a872fc

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

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

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

From kbarrett at openjdk.org  Thu Jul 10 20:56:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 10 Jul 2025 20:56:43 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v2]
In-Reply-To: <WjBzjdTZLh9-XBbAgWJL7FmqX_OsrEDKOBD6cqRYTVg=.b9b95d6b-dffe-4375-95a5-2599f5685080@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <WjBzjdTZLh9-XBbAgWJL7FmqX_OsrEDKOBD6cqRYTVg=.b9b95d6b-dffe-4375-95a5-2599f5685080@github.com>
Message-ID: <Emiy2tWaCDTCezsIglV6VWWv66d9yAlMaISFO0L6gy0=.e6367112-5c3f-4a24-b495-89255d4ffffe@github.com>

On Thu, 10 Jul 2025 13:05:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * kbarret review:
>     - restructure code in `try_collect_concurrently`
>     - fix asserts - they only worked in the test because of whitebox being active
>     - fix comments
>   * threalmdoerr review:
>     - fix test to be more lenient

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1755:

> 1753:         old_marking_started_before = old_marking_started_after;
> 1754:       }
> 1755:     } else if (GCCause::is_codecache_requested_gc(cause) && op.marking_in_progress()) {

I wonder if this might be simpler if the codecache-request case were
completely handled by it's own clause. This would involve "duplicating" some
of the user-request case. But I think that could be done by chunking that into
a couple helper functions, bounded by the existing assertions in the
user-request case. So something like this (I don't love the names of the
helpers here):

if (is_codecache_requested_gc(cause)) {
  if (op.marking_in_progress()) {
    LOG... ;
    return true;
  }
  // is there some assert similar to the user-request assert that makes sense here?
  if (wait_for_completion(old_marking_started_before,
                          old_marking_started_after,
                          old_marking_completed_after)) {
    return true;
  }
  // is there some assert similar to the user-request assert that makes sense here?
  if (need_normal_retry(op)) {
    continue;
  }
}

And similarly in the user-request case.  And obviously with more comments :)

While looking at that, I noticed that the whitebox control stall in the
user-request case is doing exactly what the comment about it says not to do.
It is waiting for control to be released, while the comment says not to do
that. This of course means there could be multiple complete collections (and
not just STW full collections) before it can proceed. This seems to be in the
initial published webrev for JDK-8240239. The immediately preceding (draft,
non-public) webrev has that comment but different code, so it looks like the
code was changed but the comment wasn't updated. Bad Kim!

I will file a bug for that and assign it to myself. If you decide to adopt
something like the above suggested refactoring, just retain that code and
comment as-is. I'll see if I can recall what happened there, and update the
comment accordingly. Unfortunately, the (non-public) email discussion between
those versions doesn't make any mention of this change.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1757:

> 1755:     } else if (GCCause::is_codecache_requested_gc(cause) && op.marking_in_progress()) {
> 1756:         // For a CodeCache requested GC, before marking, progress is ensured as the
> 1757:         // following Remark pause unloads code (and signals the requestr such).

spelling: requestr

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1768:

> 1766:       // (1) the VMOp successfully performed a GC,
> 1767:       // (2) a concurrent cycle was already in progress and we were
> 1768:       //     before the Remark pause for CodeCache requested GCs,

I think this comment change is no longer needed.  Which is good, because I find it confusingly
ambiguous, but had trouble figuring out what it should say instead. I think the original is fine,
because we're in a non-codecache request context.

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

PR Review: https://git.openjdk.org/jdk/pull/26189#pullrequestreview-3006657505
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2198721164
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2198307729
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2198312027

From wkemper at openjdk.org  Thu Jul 10 22:25:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 22:25:23 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in op_degenerated
Message-ID: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>

Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.

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

Commit messages:
 - STW collections cannot unload classes before reclaiming garbage

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

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

From wkemper at openjdk.org  Thu Jul 10 22:28:46 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 22:28:46 GMT
Subject: [jdk25] Integrated: 8357976: GenShen crash in swap_card_tables: Should
 be clean
In-Reply-To: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
References: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
Message-ID: <6hhL__DpEBM36_nQlqGIyygV22mSPLA8TLvPchnf2ig=.3ff14783-cb3f-4a47-a607-89618293ee9f@github.com>

On Thu, 10 Jul 2025 15:59:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes correctness issue in Shenandoah.

This pull request has now been integrated.

Changeset: 4d5211cc
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d5211ccb0dce13eeef9b7f12d014dd58957c854
Stats:     17 lines in 2 files changed: 10 ins; 4 del; 3 mod

8357976: GenShen crash in swap_card_tables: Should be clean

Reviewed-by: shade
Backport-of: 382f870cd53d69dfc1d2b96150aa2c026e47f642

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

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

From wkemper at openjdk.org  Thu Jul 10 22:37:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 22:37:23 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
 [v2]
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <Fhok0rQR6ovXxjpeTzqcYM54Xj1FL_OSnCKFj8PcYOY=.8456cc8b-8c95-4d2e-9be4-a040478b83f7@github.com>

> Clean backport. Fixes bad pointer in assert.

William Kemper 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 two additional commits since the last revision:

 - Merge branch 'jdk-25' into backport-earthling-amzn-1de2acea-jdk25
 - Backport 1de2acea77da57fd44b214332a73cc6621806e4d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26228/files
  - new: https://git.openjdk.org/jdk/pull/26228/files/889f5af1..abf285a2

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

  Stats: 97 lines in 12 files changed: 55 ins; 16 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26228/head:pull/26228

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

From ysr at openjdk.org  Fri Jul 11 02:13:40 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Jul 2025 02:13:40 GMT
Subject: RFR: 8350050: Shenandoah: remove support for ShenandoahPacing feature
Message-ID: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>

Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, has been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational Shenan
 doah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.

Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.

We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.


### SpecJBB
[Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]

  Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
--------------------------|--------------------|----------------------------------|
+ShenandoahPacing         |              *22.1*          |                                21.5                   |
-ShenandoahPacing          |              24.8            |                               *26.9*                |
Feature deleted entirely    |            **24.4**       |                              **27.6**              |

### Testing:
- SPECjbb
- Code Pipeline Stress
- Perf Dashboard
----------------------------------------------------------------------------------

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

Commit messages:
 - Fix some comments and user instructions / documentation that refer to
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - ... and 6 more: https://git.openjdk.org/jdk/compare/ee0d309b...645bb879

Changes: https://git.openjdk.org/jdk/pull/24002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24002&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350050
  Stats: 781 lines in 19 files changed: 0 ins; 774 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24002/head:pull/24002

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

From ysr at openjdk.org  Fri Jul 11 02:13:40 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Jul 2025 02:13:40 GMT
Subject: RFR: 8350050: Shenandoah: remove support for ShenandoahPacing
 feature
In-Reply-To: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
Message-ID: <a1C4HRWAjRLJ-eGGKUwyQutDaC-C_ev4RPq3EBkFl6I=.6227a6b0-85e5-4351-8282-f09e86dc3114@github.com>

On Wed, 12 Mar 2025 01:11:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, has been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational Shen
 andoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
> 
> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
> 
> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
> 
> 
> ### SpecJBB
> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
> 
>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
> --------------------------|--------------------|----------------------------------|
> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
> -ShenandoahPacing          |              24.8            |                               *26.9*                |
> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
> 
> ### Testing:
> - SPECjbb
> - Code Pipeline Stress
> - Perf Dashboard
> ------...

Getting some performance numbers and will open up for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/24002#issuecomment-2873698421

From shade at openjdk.org  Fri Jul 11 05:46:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 05:46:42 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
 [v2]
In-Reply-To: <Fhok0rQR6ovXxjpeTzqcYM54Xj1FL_OSnCKFj8PcYOY=.8456cc8b-8c95-4d2e-9be4-a040478b83f7@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
 <Fhok0rQR6ovXxjpeTzqcYM54Xj1FL_OSnCKFj8PcYOY=.8456cc8b-8c95-4d2e-9be4-a040478b83f7@github.com>
Message-ID: <BhVfgaJhJIJALXJx3f1sNRYBBG49tEgV9BklRxLB3Hg=.84c87f22-bc5f-4531-89e7-24329b861e77@github.com>

On Thu, 10 Jul 2025 22:37:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Clean backport. Fixes bad pointer in assert.
>
> William Kemper 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 two additional commits since the last revision:
> 
>  - Merge branch 'jdk-25' into backport-earthling-amzn-1de2acea-jdk25
>  - Backport 1de2acea77da57fd44b214332a73cc6621806e4d

Looks fine for JDK 25.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26228#pullrequestreview-3008684686

From rkennke at openjdk.org  Fri Jul 11 07:36:41 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 11 Jul 2025 07:36:41 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297 [v2]
In-Reply-To: <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
Message-ID: <O3VnorJcvpdlNZnZVPBWtVx_wcCovI_xaRQtY0boq2I=.ac4a31e8-795c-4652-8f4d-aff349a6b283@github.com>

On Thu, 10 Jul 2025 06:32:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
>> 
>> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
>> 
>> For details about this issue, please see the Jira description and comment. The short version is:
>> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
>> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
>> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
>> 
>> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
>> 
>> Therefore I just changed the assertions.
>> 
>> But I would like to hear other people's opinion on this.
>> 
>> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.
>
> Thomas Stuefe 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:
> 
>  - Alekseys additions
>  - Also check array klass
>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>  - also fix ShenandoahVerifier
>  - start

Looks good, thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26187#pullrequestreview-3009025955

From stuefe at openjdk.org  Fri Jul 11 08:05:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 11 Jul 2025 08:05:49 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297 [v2]
In-Reply-To: <O3VnorJcvpdlNZnZVPBWtVx_wcCovI_xaRQtY0boq2I=.ac4a31e8-795c-4652-8f4d-aff349a6b283@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
 <O3VnorJcvpdlNZnZVPBWtVx_wcCovI_xaRQtY0boq2I=.ac4a31e8-795c-4652-8f4d-aff349a6b283@github.com>
Message-ID: <Ew3ecT56ZxQwIZcajN673PzWpYNPj8uMfdAB1t_dsLw=.6c8545e5-c976-4188-a807-bd68a45ebe00@github.com>

On Fri, 11 Jul 2025 07:34:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe 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:
>> 
>>  - Alekseys additions
>>  - Also check array klass
>>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>>  - also fix ShenandoahVerifier
>>  - start
>
> Looks good, thank you!

Thank you, @rkennke !

I will integrate now, since this bug hinders other work I do. @earthling-amzn requested changes to comments, but those comments were removed completely, so I think that request is fulfilled :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3061125318

From stuefe at openjdk.org  Fri Jul 11 08:05:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 11 Jul 2025 08:05:49 GMT
Subject: Integrated: 8361342: Shenandoah: Evacuation may assert on invalid
 mirror object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <R0RSxRjeMLZIReFLlSfU4BH-vIdE8JgsEN5E9dAkbzY=.97065230-5590-4747-ad2e-ec3f19dc0122@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

This pull request has now been integrated.

Changeset: 445e5ecd
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/445e5ecd98f41d4d625af5731f7b5d10c9225e49
Stats:     18 lines in 2 files changed: 8 ins; 0 del; 10 mod

8361342: Shenandoah: Evacuation may assert on invalid mirror object after JDK-8340297

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Reviewed-by: shade, rkennke

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

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

From lucy at openjdk.org  Fri Jul 11 08:51:39 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 11 Jul 2025 08:51:39 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue
In-Reply-To: <KbNf7PNszlW8jfaygFB7BGMPTnwhSzefuhVjeKoyjCc=.219cf9ec-cd24-4aa2-bc04-88479567746f@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
 <KbNf7PNszlW8jfaygFB7BGMPTnwhSzefuhVjeKoyjCc=.219cf9ec-cd24-4aa2-bc04-88479567746f@github.com>
Message-ID: <bvf6kBhXXiM2ScGYIeLvhzobuSMIMEi6JIinr4TisTI=.bea837a4-b6bf-405c-b713-b8d17462ac5c@github.com>

On Thu, 10 Jul 2025 07:12:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the jtreg test
>> gc/z/TestMappedCacheHarvest.java
>> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
>> 
>> 
>>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> 
>> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
>> young_to_old_ratio:27561965412.478878
>> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
>> `uint(young_workers * young_to_old_ratio)` .
>> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .
>
> Thanks for the review Lucy !
> May I get a second review ?

@MBaesken Thanks for the explanation. That's the mathematics. What does it tell us about the gc workload? Is it that the application mostly creates long-lived objects which all get promoted before they eventually can be collected?

Maybe this is out-of-scope for such a small fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/26186#issuecomment-3061305628

From shade at openjdk.org  Fri Jul 11 09:08:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 09:08:40 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated
In-Reply-To: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
Message-ID: <WOBk-ms6PZPo1tVT7IwutS306zP2jYJHD8o4hvj5sGk=.bf05ea3b-108b-4572-95c7-8ca2cbb3fa28@github.com>

On Thu, 10 Jul 2025 22:20:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.

Yeah, this evidently does not work, see test failures.

Architecturally, the heuristics should be looking only at region data, without looking at objects. I see we often end up calling `ShenandoahHeapRegion::required_regions(obj->size(), ...)` just to figure out how many HC regions are there in the chain. But we might as well scan regions from the given HS region, until we run out of HC regions.

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

Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26256#pullrequestreview-3009352549

From mbaesken at openjdk.org  Fri Jul 11 10:41:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Jul 2025 10:41:40 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue
In-Reply-To: <KbNf7PNszlW8jfaygFB7BGMPTnwhSzefuhVjeKoyjCc=.219cf9ec-cd24-4aa2-bc04-88479567746f@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
 <KbNf7PNszlW8jfaygFB7BGMPTnwhSzefuhVjeKoyjCc=.219cf9ec-cd24-4aa2-bc04-88479567746f@github.com>
Message-ID: <NZvQX0JiXn0gKmpbLSpoCcc1mTluU5qfWGCUQB2nN7k=.f1367006-4d26-4b77-a41e-d0c18a49917b@github.com>

On Thu, 10 Jul 2025 07:12:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the jtreg test
>> gc/z/TestMappedCacheHarvest.java
>> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
>> 
>> 
>>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> 
>> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
>> young_to_old_ratio:27561965412.478878
>> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
>> `uint(young_workers * young_to_old_ratio)` .
>> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .
>
> Thanks for the review Lucy !
> May I get a second review ?

> @MBaesken Thanks for the explanation. That's the mathematics. What does it tell us about the gc workload? Is it that the application mostly creates long-lived objects which all get promoted before they eventually can be collected?
> 
> Maybe this is out-of-scope for such a small fix.

The ZGC people can probably comment on this.
Not sure what is 'normal'  / usual there with ZGC.

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

PR Comment: https://git.openjdk.org/jdk/pull/26186#issuecomment-3061679069

From tschatzl at openjdk.org  Fri Jul 11 10:46:50 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Jul 2025 10:46:50 GMT
Subject: RFR: 8361706: Parallel weak klass link cleaning does not clean out
 previous klasses
Message-ID: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>

Hi all,

  please review this fix to parallel weak klass link cleaning.

`KlassCleaningTask::work()` misses cleaning out previous versions of klasses (created by JVMTI class redefinition) as the regular single-threaded variant would do when calling `Klass::clean_weak_klass_links()` with `clean_live_klasses = true`.

The fix moves the cleaning of weak klass links for previous versions of the klass into `InstanceKlass::clean_weak_instanceklass_links()`.

Testing: gha, tier1-5, many runs of `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java`(with JDK-8361952 also out for review)

Thanks,
  Thomas

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

Commit messages:
 - * remove patch for JDK-8361952
 - * working version, do not recursively clean out
 - * another attempt
 - 8361706

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

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

From eosterlund at openjdk.org  Fri Jul 11 11:25:37 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 11 Jul 2025 11:25:37 GMT
Subject: RFR: 8361706: Parallel weak klass link cleaning does not clean out
 previous klasses
In-Reply-To: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
References: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
Message-ID: <dg_xvuQ6egW_SbhRCLyESf7lYT-fGOQNf-rZb9aLw28=.a95623b6-9010-4e44-887f-7864a21ed76f@github.com>

On Fri, 11 Jul 2025 10:38:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to parallel weak klass link cleaning.
> 
> `KlassCleaningTask::work()` misses cleaning out previous versions of klasses (created by JVMTI class redefinition) as the regular single-threaded variant would do when calling `Klass::clean_weak_klass_links()` with `clean_live_klasses = true`.
> 
> The fix moves the cleaning of weak klass links for previous versions of the klass into `InstanceKlass::clean_weak_instanceklass_links()`.
> 
> Testing: gha, tier1-5, many runs of `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java`(with JDK-8361952 also out for review)
> 
> Thanks,
>   Thomas

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26263#pullrequestreview-3009862639

From coleenp at openjdk.org  Fri Jul 11 17:51:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 11 Jul 2025 17:51:40 GMT
Subject: RFR: 8361706: Parallel weak klass link cleaning does not clean out
 previous klasses
In-Reply-To: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
References: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
Message-ID: <b1dkj1MxRfSFOK7fxYvnywl-9TAS9lPc2crtNuYVgPI=.5d2ce08f-0af7-4339-a85b-5cafe1520c19@github.com>

On Fri, 11 Jul 2025 10:38:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to parallel weak klass link cleaning.
> 
> `KlassCleaningTask::work()` misses cleaning out previous versions of klasses (created by JVMTI class redefinition) as the regular single-threaded variant would do when calling `Klass::clean_weak_klass_links()` with `clean_live_klasses = true`.
> 
> The fix moves the cleaning of weak klass links for previous versions of the klass into `InstanceKlass::clean_weak_instanceklass_links()`.
> 
> Testing: gha, tier1-5, many runs of `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java`(with JDK-8361952 also out for review)
> 
> Thanks,
>   Thomas

Can you make InstanceKlass::clean_weak_instanceklass_links() protected?  If not, this looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26263#pullrequestreview-3011375434

From xpeng at openjdk.org  Fri Jul 11 17:58:22 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 11 Jul 2025 17:58:22 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch (byte or
 word?)
Message-ID: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>

In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.

It should be just one line change like:

if (alloc_capacity(r) >= min_size * HeapWordSize) {
   ...
}



### Test
- [x] make test TEST=hotspot_gc_shenandoah

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

Commit messages:
 - Bug fix: unit mismatch

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

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

From shade at openjdk.org  Fri Jul 11 17:58:22 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 17:58:22 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch (byte
 or word?)
In-Reply-To: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
Message-ID: <ACUxxyPULO5HaI92kD9ldLPETWtvG6EZJMnvHsUztPs=.a792b59e-bc05-42b8-9e0c-336cc115b201@github.com>

On Fri, 11 Jul 2025 07:12:31 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
> ), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.
> 
> It should be just one line change like:
> 
> if (alloc_capacity(r) >= min_size * HeapWordSize) {
>    ...
> }
> 
> 
> 
> ### Test
> - [x] make test TEST=hotspot_gc_shenandoah

This looks reasonable.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26259#pullrequestreview-3009267508

From xpeng at openjdk.org  Fri Jul 11 17:58:22 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 11 Jul 2025 17:58:22 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch (byte
 or word?)
In-Reply-To: <ACUxxyPULO5HaI92kD9ldLPETWtvG6EZJMnvHsUztPs=.a792b59e-bc05-42b8-9e0c-336cc115b201@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
 <ACUxxyPULO5HaI92kD9ldLPETWtvG6EZJMnvHsUztPs=.a792b59e-bc05-42b8-9e0c-336cc115b201@github.com>
Message-ID: <xXGwqGqgirofy8SiwC90tjy6wKiUHqGZ7BYXd4prVSo=.9c16b77b-5abd-43fc-839f-adee30eeb9e8@github.com>

On Fri, 11 Jul 2025 08:34:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This looks reasonable.

Thank you! @shipilev

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

PR Comment: https://git.openjdk.org/jdk/pull/26259#issuecomment-3063216917

From shade at openjdk.org  Fri Jul 11 18:00:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 18:00:45 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch (byte
 or word?)
In-Reply-To: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
Message-ID: <XrxhEGZEQRxLcVtBNv8W0Fhqzfn4BivhvBZRg99jhy0=.4ef10a42-7c28-4aa1-b4a1-13272e67e724@github.com>

On Fri, 11 Jul 2025 07:12:31 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
> ), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.
> 
> It should be just one line change like:
> 
> if (alloc_capacity(r) >= min_size * HeapWordSize) {
>    ...
> }
> 
> 
> 
> ### Test
> - [x] make test TEST=hotspot_gc_shenandoah

I just dropped the question from the synopsis, though. Because it is clear from the patch there is a problem. You'll need to adjust the PR title a bit.

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

PR Comment: https://git.openjdk.org/jdk/pull/26259#issuecomment-3063226717

From duke at openjdk.org  Fri Jul 11 18:41:21 2025
From: duke at openjdk.org (Rui Li)
Date: Fri, 11 Jul 2025 18:41:21 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
Message-ID: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>

Add logging for Shenandoah as well as Generational Shenandoah. 

Log samples:


######################################
Before gc
######################################
[0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
[0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
[0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
[0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
[0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
[0.231s][debug][gc,heap      ] GC(0)  Reserved region:
[0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
[0.231s][debug][gc,heap      ] GC(0)  Collection set:
[0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
[0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
[0.231s][debug][gc,heap      ] GC(0) 
[0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
[0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
[0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K




######################################
After gc
######################################
[2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
[2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
[2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
[2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
[2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
[2.067s][debug][gc,heap        ] GC(11)  Reserved region:
[2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
[2.067s][debug][gc,heap        ] GC(11)  Collection set:
[2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
[2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
[2.067s][debug][gc,heap        ] GC(11) 
[2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
[2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
[2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

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

Commit messages:
 - 8357818: Shenandoah doesn't use shared API for printing heap before/after GC

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

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

From wkemper at openjdk.org  Fri Jul 11 18:50:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Jul 2025 18:50:42 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch
In-Reply-To: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
Message-ID: <nPQ8Dy-BcWPUfT76N5DRPpQfO3xP_fMfoMTotQ2nxUM=.3074c74c-1daf-4569-a6d1-a0452f89ee53@github.com>

On Fri, 11 Jul 2025 07:12:31 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
> ), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.
> 
> It should be just one line change like:
> 
> if (alloc_capacity(r) >= min_size * HeapWordSize) {
>    ...
> }
> 
> 
> 
> ### Test
> - [x] make test TEST=hotspot_gc_shenandoah

Nice catch!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26259#pullrequestreview-3011528633

From xpeng at openjdk.org  Fri Jul 11 20:12:47 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 11 Jul 2025 20:12:47 GMT
Subject: Integrated: 8361948: Shenandoah: region free capacity unit mismatch
In-Reply-To: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
Message-ID: <pWGZXk-WISixM4wZerBc6ss_ejquOv5z-ueoqXxsGLM=.95e9c91f-2748-4c30-a51a-391cf9c0f5cd@github.com>

On Fri, 11 Jul 2025 07:12:31 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
> ), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.
> 
> It should be just one line change like:
> 
> if (alloc_capacity(r) >= min_size * HeapWordSize) {
>    ...
> }
> 
> 
> 
> ### Test
> - [x] make test TEST=hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 46988e10
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46988e1073e9a2b47491c90143b1f261fe56da56
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361948: Shenandoah: region free capacity unit mismatch

Reviewed-by: shade, wkemper

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

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

From wkemper at openjdk.org  Fri Jul 11 21:46:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Jul 2025 21:46:38 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
Message-ID: <LmjrSaOKF8fn708iUyP_OiXbuZgYDrT87trewAkLN-s=.76ff03d1-08d9-461c-b627-5b1e97239b77@github.com>

On Fri, 11 Jul 2025 18:24:56 GMT, Rui Li <duke at openjdk.org> wrote:

> Add logging for Shenandoah as well as Generational Shenandoah. 
> 
> Log samples:
> 
> 
> ######################################
> Before gc
> ######################################
> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.231s][debug][gc,heap      ] GC(0) 
> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> 
> 
> 
> ######################################
> After gc
> ######################################
> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
> [2.067s][debug][gc,heap        ] GC(11) 
> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

This looks good to me. Someday we should look at combining some of the other related messages (free set status, e.g.) into `ShenandoahHeap::print_heap_on`.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26272#pullrequestreview-3012097755

From ysr at openjdk.org  Fri Jul 11 22:07:39 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Jul 2025 22:07:39 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
Message-ID: <TBZZcx6kinFlpQAOZhOa6TO4OmilbrPqZNjQ8Xt1qBs=.b14d9d22-f75f-4aec-8cce-26c913502d1a@github.com>

On Fri, 11 Jul 2025 18:24:56 GMT, Rui Li <duke at openjdk.org> wrote:

> Add logging for Shenandoah as well as Generational Shenandoah. 
> 
> Log samples:
> 
> 
> ######################################
> Before gc
> ######################################
> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.231s][debug][gc,heap      ] GC(0) 
> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> 
> 
> 
> ######################################
> After gc
> ######################################
> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
> [2.067s][debug][gc,heap        ] GC(11) 
> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

Left some comments in PR. Will complete review by EOD.

> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):

Looks like Shenandoah/GenShen are missing `increment_total_collections(...)`, which updates the `invocations=...` part. I'd roughly expect it to equal the GC id (or be a tad smaller) `GC(11)`.

> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions

A potential enhancement for GenShen would be to provide used region counts for old and young separately, and to add the "Generational" prefix in:

> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap

Rest looks good, although I want to verify that we print along all gc cycles, not just concurrent ones, as seems to be the case here.

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

PR Review: https://git.openjdk.org/jdk/pull/26272#pullrequestreview-3012130902
PR Comment: https://git.openjdk.org/jdk/pull/26272#issuecomment-3063991526

From wkemper at openjdk.org  Fri Jul 11 22:30:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Jul 2025 22:30:37 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <TBZZcx6kinFlpQAOZhOa6TO4OmilbrPqZNjQ8Xt1qBs=.b14d9d22-f75f-4aec-8cce-26c913502d1a@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
 <TBZZcx6kinFlpQAOZhOa6TO4OmilbrPqZNjQ8Xt1qBs=.b14d9d22-f75f-4aec-8cce-26c913502d1a@github.com>
Message-ID: <a2D0dYrWX3Pqegw4wLH43XGW2WkzP7STI0gZC44-NAo=.d9781f9c-a490-43d6-a74b-e1fcaf054872@github.com>

On Fri, 11 Jul 2025 22:03:00 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Add logging for Shenandoah as well as Generational Shenandoah. 
>> 
>> Log samples:
>> 
>> 
>> ######################################
>> Before gc
>> ######################################
>> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
>> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
>> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
>> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
>> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
>> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
>> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
>> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
>> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
>> [0.231s][debug][gc,heap      ] GC(0) 
>> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
>> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
>> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
>> 
>> 
>> 
>> 
>> ######################################
>> After gc
>> ######################################
>> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
>> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
>> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
>> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
>> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
>> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
>> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
>> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
>> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
>> [2.067s][debug][gc,heap        ] GC(11) 
>> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
>> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
>> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K
>
>> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> 
> Looks like Shenandoah/GenShen are missing `increment_total_collections(...)`, which updates the `invocations=...` part. I'd roughly expect it to equal the GC id (or be a tad smaller) `GC(11)`.
> 
>> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
>> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
>> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> 
> A potential enhancement for GenShen would be to provide used region counts for old and young separately, and to add the "Generational" prefix in:
> 
>> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> 
> Rest looks good, although I want to verify that we print along all gc cycles, not just concurrent ones, as seems to be the case here.

@ysramakrishna , good catch with `increment_total_collections`. The `print_before` and `print_after` calls surround the switch case that handles all GCs (conc, degen, full).

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

PR Comment: https://git.openjdk.org/jdk/pull/26272#issuecomment-3064067648

From ysr at openjdk.org  Sun Jul 13 04:29:50 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sun, 13 Jul 2025 04:29:50 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
Message-ID: <vJskhv4w7IchCtx5Oaq0mRHOrqmfMb6H_a5Aw-H3TxQ=.4807dfc7-9bd0-4e1e-be7e-2bf988af825a@github.com>

On Fri, 11 Jul 2025 18:24:56 GMT, Rui Li <duke at openjdk.org> wrote:

> Add logging for Shenandoah as well as Generational Shenandoah. 
> 
> Log samples:
> 
> 
> ######################################
> Before gc
> ######################################
> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.231s][debug][gc,heap      ] GC(0) 
> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> 
> 
> 
> ######################################
> After gc
> ######################################
> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
> [2.067s][debug][gc,heap        ] GC(11) 
> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

Reviewed; looks good, modulo earlier comments for additional information which might be useful for genshen.

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

PR Review: https://git.openjdk.org/jdk/pull/26272#pullrequestreview-3013859684

From duke at openjdk.org  Sun Jul 13 18:31:59 2025
From: duke at openjdk.org (duke)
Date: Sun, 13 Jul 2025 18:31:59 GMT
Subject: Withdrawn: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <gxHnytUC-4FxOCzfdNqXlZKsKaRFxv2sIx4OQd8-3TU=.81d3f2be-1df5-45f6-b8d6-20cc4c6186df@github.com>

On Sun, 23 Feb 2025 18:53:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

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

This pull request has been closed without being integrated.

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

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

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

On Mon, 7 Jul 2025 12:36:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

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

Not yet...

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3068246695

From aph at openjdk.org  Mon Jul 14 08:25:48 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Jul 2025 08:25:48 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
Message-ID: <gvVKJFTN6wQKkP4VxBh_6-GhYNdQSoq3KQ05pj54A0Q=.7fe80989-b668-420e-b439-179786b39800@github.com>

On Mon, 7 Jul 2025 12:36:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

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

AArch64 looks good.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3015276922

From tschatzl at openjdk.org  Mon Jul 14 09:13:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:13:38 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v42]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <8lZdT84SJ-daIPPpdq35hAZ0MGa8b07TPpPa3IDp030=.201a5b52-aecb-424e-9bdf-4c64baff5e87@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 58 commits:

 - Merge branch 'master' into pull/23739
 - 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)
 - ... and 48 more: https://git.openjdk.org/jdk/compare/14c79be1...5ab928e8

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=41
  Stats: 7124 lines in 112 files changed: 2589 ins; 3594 del; 941 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 tschatzl at openjdk.org  Mon Jul 14 09:41:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:41:45 GMT
Subject: RFR: 8361706: Parallel weak klass link cleaning does not clean out
 previous klasses
In-Reply-To: <b1dkj1MxRfSFOK7fxYvnywl-9TAS9lPc2crtNuYVgPI=.5d2ce08f-0af7-4339-a85b-5cafe1520c19@github.com>
References: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
 <b1dkj1MxRfSFOK7fxYvnywl-9TAS9lPc2crtNuYVgPI=.5d2ce08f-0af7-4339-a85b-5cafe1520c19@github.com>
Message-ID: <dUq3PrWrMSl6GPUF10OSD-qL8dQbr9xwFgUevM7pgEo=.40be9cf1-2213-4fa4-ad92-c1b1551af530@github.com>

On Fri, 11 Jul 2025 17:48:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Can you make InstanceKlass::clean_weak_instanceklass_links() protected? If not, this looks good.

It is required to be public right now.

Thanks @coleenp @fisk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26263#issuecomment-3068653905

From tschatzl at openjdk.org  Mon Jul 14 09:41:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:41:46 GMT
Subject: Integrated: 8361706: Parallel weak klass link cleaning does not clean
 out previous klasses
In-Reply-To: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
References: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
Message-ID: <RwQ-oU1UeXOdF_Ra5i3FUH27EazAxpKZB4nAjaRVd6g=.24f9ba20-6401-4fdf-a203-f37b1efe4e51@github.com>

On Fri, 11 Jul 2025 10:38:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to parallel weak klass link cleaning.
> 
> `KlassCleaningTask::work()` misses cleaning out previous versions of klasses (created by JVMTI class redefinition) as the regular single-threaded variant would do when calling `Klass::clean_weak_klass_links()` with `clean_live_klasses = true`.
> 
> The fix moves the cleaning of weak klass links for previous versions of the klass into `InstanceKlass::clean_weak_instanceklass_links()`.
> 
> Testing: gha, tier1-5, many runs of `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java`(with JDK-8361952 also out for review)
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 99c299f0
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99c299f0985c8be63b9b60e589db520d83fd8033
Stats:     24 lines in 4 files changed: 12 ins; 10 del; 2 mod

8361706: Parallel weak klass link cleaning does not clean out previous klasses

Reviewed-by: eosterlund, coleenp

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

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

From tschatzl at openjdk.org  Mon Jul 14 10:12:23 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 10:12:23 GMT
Subject: RFR: 8361705: Clean up KlassCleaningTask
Message-ID: <Qu6jp4hxprf8zBurCE4slik0aiUEL6g1-j4i2-ayKLM=.180e6ed6-af6e-4b4e-8f48-996057936738@github.com>

Hi all,

  please review this cleanup of `KlassCleaningTask`, fixing some style issues.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8361705

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

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

From shade at openjdk.org  Mon Jul 14 10:19:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Jul 2025 10:19:39 GMT
Subject: RFR: 8361705: Clean up KlassCleaningTask
In-Reply-To: <Qu6jp4hxprf8zBurCE4slik0aiUEL6g1-j4i2-ayKLM=.180e6ed6-af6e-4b4e-8f48-996057936738@github.com>
References: <Qu6jp4hxprf8zBurCE4slik0aiUEL6g1-j4i2-ayKLM=.180e6ed6-af6e-4b4e-8f48-996057936738@github.com>
Message-ID: <o9PDwwMMztgsNoTNXifTlgU-i8F3rOs2n1FzkRpH-uo=.f4da2518-0bc6-48a2-83c8-993fdb3d8b9a@github.com>

On Mon, 14 Jul 2025 10:06:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this cleanup of `KlassCleaningTask`, fixing some style issues.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks OK with nits.

src/hotspot/share/gc/shared/parallelCleaning.cpp line 107:

> 105:   }
> 106: 
> 107:   return !Atomic::cmpxchg(&_clean_klass_tree_claimed, false, true);

Generally, I prefer to see `Atomic::cmpxchg(&_clean_klass_tree_claimed, false, true) == false`, because `false` here is not about the logical boolean expression, but about the "old" value`false`, which just happens to be a boolean.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26289#pullrequestreview-3015715872
PR Review Comment: https://git.openjdk.org/jdk/pull/26289#discussion_r2204483031

From ayang at openjdk.org  Mon Jul 14 10:57:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 14 Jul 2025 10:57:38 GMT
Subject: RFR: 8361705: Clean up KlassCleaningTask
In-Reply-To: <Qu6jp4hxprf8zBurCE4slik0aiUEL6g1-j4i2-ayKLM=.180e6ed6-af6e-4b4e-8f48-996057936738@github.com>
References: <Qu6jp4hxprf8zBurCE4slik0aiUEL6g1-j4i2-ayKLM=.180e6ed6-af6e-4b4e-8f48-996057936738@github.com>
Message-ID: <Hm2rpOBNLNfYS8RWc9fWpxRPT_AToRoNEDhOX-4uDBw=.ccf1ef8c-6d14-4936-a228-092afa1faf1c@github.com>

On Mon, 14 Jul 2025 10:06:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this cleanup of `KlassCleaningTask`, fixing some style issues.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26289#pullrequestreview-3015847806

From wkemper at openjdk.org  Mon Jul 14 16:53:45 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 14 Jul 2025 16:53:45 GMT
Subject: [jdk25] Integrated: 8361529: GenShen: Fix bad assert in swap card
 tables
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <N3YUS6bETVc5O8bJBbitBiZIVtSAZ8EmUJ8oBbMcEJM=.50fa599a-6c71-495c-b6e3-86735d6ce295@github.com>

On Wed, 9 Jul 2025 21:06:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes bad pointer in assert.

This pull request has now been integrated.

Changeset: 20fc8f74
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20fc8f74d5627119cc2397610083f16e54fedc93
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361529: GenShen: Fix bad assert in swap card tables

Reviewed-by: shade
Backport-of: 1de2acea77da57fd44b214332a73cc6621806e4d

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

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

From wkemper at openjdk.org  Mon Jul 14 22:32:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 14 Jul 2025 22:32:41 GMT
Subject: RFR: 8350050: Shenandoah: Disable and purge allocation pacing
 support
In-Reply-To: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
Message-ID: <afoU7QJP-J6IGDKVZ7YE5797davpJFXxNf0x3wgSWec=.d64c9fa0-cbc0-401b-82e2-a408d75aa3c0@github.com>

On Wed, 12 Mar 2025 01:11:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, have been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational She
 nandoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
> 
> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
> 
> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
> 
> 
> ### SpecJBB
> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
> 
>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
> --------------------------|--------------------|----------------------------------|
> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
> -ShenandoahPacing          |              24.8            |                               *26.9*                |
> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
> 
> ### Testing:
> - SPECjbb
> - Code Pipeline Stress
> - Perf Dashboard
> -----...

This is a huge simplification. Looks good, but there is a now unused variable we remove.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 839:

> 837: 
> 838:             _heap->marked_object_oop_iterate(r, &cl, update_watermark);
> 839:             region_progress = true;

I don't think we need this `region_progress` variable anymore.

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24002#pullrequestreview-3017987874
PR Review Comment: https://git.openjdk.org/jdk/pull/24002#discussion_r2205929549

From wkemper at openjdk.org  Mon Jul 14 23:32:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 14 Jul 2025 23:32:55 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v2]
In-Reply-To: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
Message-ID: <CYjxc26_190b82zsRno3GVl-QHmvQw-9W5iCQfqe2Jw=.f1c41a84-ec13-407e-b2a1-dc08e3876c1f@github.com>

> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.

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

 - Reclaim humongous regions from start to end (do not use oop::size).
 - Revert "STW collections cannot unload classes before reclaiming garbage"
   
   This reverts commit ae8079386eb34cf1351534ede7d7df8f81b50174.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26256/files
  - new: https://git.openjdk.org/jdk/pull/26256/files/ae807938..cb63787d

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

  Stats: 96 lines in 3 files changed: 40 ins; 49 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26256/head:pull/26256

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

From kbarrett at openjdk.org  Tue Jul 15 06:07:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Jul 2025 06:07:41 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v3]
In-Reply-To: <SAyZYkt7EDJDe5SZRM6cLrpYDi1Xog74IyYz5wOvcQU=.3343fbcd-2f09-4af0-8b81-172dd04eb7e4@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <SAyZYkt7EDJDe5SZRM6cLrpYDi1Xog74IyYz5wOvcQU=.3343fbcd-2f09-4af0-8b81-172dd04eb7e4@github.com>
Message-ID: <059GBakGm5FWdcStuQygNAjbw3JYz_IZ7BXmLcSj4uU=.5be6b8e0-5557-4876-9249-ee25624d41c7@github.com>

On Fri, 4 Jul 2025 12:01:00 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 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

As is, I'm not entirely convinced this change is an improvement. We now have 3
separate places that are fairly similar (each calls some collection of
functions and maybe some additional functions). It's not at all obvious what
the reasoning for the various differences are.

Interleaving comments in each place mentioning the missing calls, and an
explanatory comment in each place about the overall task would be helpful. The
SO_xxx flags and how they were used at least provided some hints for the
latter, but now even those hints are gone.

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

PR Review: https://git.openjdk.org/jdk/pull/26038#pullrequestreview-3018793377

From shade at openjdk.org  Tue Jul 15 07:43:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 07:43:38 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v2]
In-Reply-To: <CYjxc26_190b82zsRno3GVl-QHmvQw-9W5iCQfqe2Jw=.f1c41a84-ec13-407e-b2a1-dc08e3876c1f@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
 <CYjxc26_190b82zsRno3GVl-QHmvQw-9W5iCQfqe2Jw=.f1c41a84-ec13-407e-b2a1-dc08e3876c1f@github.com>
Message-ID: <HojpKpsHMQPsb_NXVY7M_vvOXC8k3N4FjVroT-ZfGno=.822738d8-7bfc-460e-b55f-3df16b6836ca@github.com>

On Mon, 14 Jul 2025 23:32:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reclaim humongous regions from start to end (do not use oop::size).
>  - Revert "STW collections cannot unload classes before reclaiming garbage"
>    
>    This reverts commit ae8079386eb34cf1351534ede7d7df8f81b50174.

Three things:

1. Bug synopsis should generally reflect what is being done, not what the symptom is. There is a leeway: it can describe the _problem_ that is being solved.

2. See the comment, "Reclaim from tail". Have you verified reclaiming from head is fine? If not, I think it is better to find the tail first, then walk it backwards. In fact, maybe it is a good time to introduce an utility method in `ShenandoahHeapRegion` that tells the tail of HC chain. There is already `ShenandoahHeapRegion::humongous_start_region` that can have a symmetric `ShenandoahHeapRegion::humongous_end_region`.

3. Generally, it looks brittle to touch objects during any heuristics calculation due to these lifecycle problems. There is another instance of `ShenandoahHeapRegion::required_regions(obj->size() * HeapWordSize);` in `ShenandoahGenerationalHeuristics::choose_collection_set` -- is it affected by the same issue?

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

PR Review: https://git.openjdk.org/jdk/pull/26256#pullrequestreview-3019102674

From ayang at openjdk.org  Tue Jul 15 08:29:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 15 Jul 2025 08:29:23 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v4]
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: <b2IAtjznnLPiZYVGmbN75PZknMKBTmbyHUUA-mfpuj4=.b09d2ed7-add0-40a8-b345-c2bd0df82f72@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 six additional commits since the last revision:

 - review
 - Merge branch 'master' into sgc-roots
 - 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/8b779888..59432994

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

  Stats: 17290 lines in 564 files changed: 7997 ins; 5358 del; 3935 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  Tue Jul 15 08:29:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 15 Jul 2025 08:29:23 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v3]
In-Reply-To: <059GBakGm5FWdcStuQygNAjbw3JYz_IZ7BXmLcSj4uU=.5be6b8e0-5557-4876-9249-ee25624d41c7@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <SAyZYkt7EDJDe5SZRM6cLrpYDi1Xog74IyYz5wOvcQU=.3343fbcd-2f09-4af0-8b81-172dd04eb7e4@github.com>
 <059GBakGm5FWdcStuQygNAjbw3JYz_IZ7BXmLcSj4uU=.5be6b8e0-5557-4876-9249-ee25624d41c7@github.com>
Message-ID: <7IpW5Lli9OZRvPeFnD9aw_WAzL9ZZF0p7_A5ub3joMI=.b77cc0a8-e14c-4de3-8b73-1263aed9bf4d@github.com>

On Tue, 15 Jul 2025 06:04:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Interleaving comments in each place mentioning the missing calls, and an
explanatory comment in each place about the overall task would be helpful.

Added comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/26038#issuecomment-3072645242

From iwalulya at openjdk.org  Tue Jul 15 17:15:50 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 15 Jul 2025 17:15:50 GMT
Subject: RFR: 8362278: G1: Consolidate functions for recording pause start time
Message-ID: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>

Hi,

Please review this refactoring change to unify the recording of GC Pause start-time.

Testing: Tier 1

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

Commit messages:
 - clean out
 - init

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

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

From wkemper at openjdk.org  Tue Jul 15 17:42:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 15 Jul 2025 17:42:42 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v2]
In-Reply-To: <CYjxc26_190b82zsRno3GVl-QHmvQw-9W5iCQfqe2Jw=.f1c41a84-ec13-407e-b2a1-dc08e3876c1f@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
 <CYjxc26_190b82zsRno3GVl-QHmvQw-9W5iCQfqe2Jw=.f1c41a84-ec13-407e-b2a1-dc08e3876c1f@github.com>
Message-ID: <Iq2A4d8lm7ZuIdmn04-1nXmCmaRvja5Ms_Od2VWUT3A=.0acb78db-301a-4746-aa55-fdde09bf0ff7@github.com>

On Mon, 14 Jul 2025 23:32:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reclaim humongous regions from start to end (do not use oop::size).
>  - Revert "STW collections cannot unload classes before reclaiming garbage"
>    
>    This reverts commit ae8079386eb34cf1351534ede7d7df8f81b50174.

Thanks for the review. 
1. I will update the synopsis when we settle on the approach to solve this issue. To be clear, by "synopsis" you mean the description of the pull request?
2. Yes, I looked at all usages of `ShenandoahHeapRegion::is_humongous*` and didn't see any cases that would be affected by this change. All of the GHA and pipeline tests passed. The comment is over 7 years old. Also, this code to make immediate trash of unmarked humongous objects only runs on a safepoint (final-mark, degen or full-gc). I will, however, run the jtreg tests again with trace logging enabled out of an abundance of caution.
3. Yes, I agree, the code is brittle. For reasons lost to history, STW collections (degen and full-gc) perform weak roots, weak refs and class unloading _before_ choosing the collection set (this order is the reverse of concurrent GCs). My initial attempt to put these steps in the same order for STW collections met with... resistance. Many assertions failed for what looks like erroneous reasons. The other instance of `ShenandoahHeapRegion::required_regions(obj->size() * HeapWordSize);` is safe here because this is a marked humongous object (and should _not_ have its class unloaded). I can revisit my initial approach, but I'm not sure I want to open that can of worms. I'd rather spend the time on removing STW collections.

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

PR Comment: https://git.openjdk.org/jdk/pull/26256#issuecomment-3074617563

From shade at openjdk.org  Tue Jul 15 19:10:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 19:10:42 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v2]
In-Reply-To: <CYjxc26_190b82zsRno3GVl-QHmvQw-9W5iCQfqe2Jw=.f1c41a84-ec13-407e-b2a1-dc08e3876c1f@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
 <CYjxc26_190b82zsRno3GVl-QHmvQw-9W5iCQfqe2Jw=.f1c41a84-ec13-407e-b2a1-dc08e3876c1f@github.com>
Message-ID: <4otVFo-w-uwQBjU6CmOHzvBmOzoxmDWWzesZiDjTRmA=.93ec0913-a270-4a06-8a67-3f65b0efeb04@github.com>

On Mon, 14 Jul 2025 23:32:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reclaim humongous regions from start to end (do not use oop::size).
>  - Revert "STW collections cannot unload classes before reclaiming garbage"
>    
>    This reverts commit ae8079386eb34cf1351534ede7d7df8f81b50174.

> To be clear, by "synopsis" you mean the description of the pull request?

Yes. 

All right then, improve a synopsis and then we are good to go.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1468:

> 1466:     region->make_trash_immediate();
> 1467:     regions_trashed++;
> 1468:     region = get_region(region->index() + 1);

Micro-optimization opportunity: track `index` as a local variable without introducing memory dependency on another region. Would likely pipeline a bit better.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26256#pullrequestreview-3021951860
PR Review Comment: https://git.openjdk.org/jdk/pull/26256#discussion_r2208433549

From tschatzl at openjdk.org  Tue Jul 15 19:17:16 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Jul 2025 19:17:16 GMT
Subject: RFR: 8362271: G1: Improve G1CollectorState::clearing_bitmap name
Message-ID: <9eL7BlKr0k3mx-cZYzE4BiXBqDazMb_0Tpgj_fuoWbA=.3d390fce-90d2-440d-93ab-b2d684688069@github.com>

Hi all,

  can I have reviews for this trivial rename of the `clearing_bitmap` member in `G1CollectorState` to align it with the other related ones that read `<something>_in_progress`?

Testing: local compilation, gha

Thanks,
  Thomas

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

Commit messages:
 - 8362271

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

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

From sangheki at openjdk.org  Tue Jul 15 20:07:41 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Tue, 15 Jul 2025 20:07:41 GMT
Subject: RFR: 8362271: G1: Improve G1CollectorState::clearing_bitmap name
In-Reply-To: <9eL7BlKr0k3mx-cZYzE4BiXBqDazMb_0Tpgj_fuoWbA=.3d390fce-90d2-440d-93ab-b2d684688069@github.com>
References: <9eL7BlKr0k3mx-cZYzE4BiXBqDazMb_0Tpgj_fuoWbA=.3d390fce-90d2-440d-93ab-b2d684688069@github.com>
Message-ID: <rdwIiNSKHvgnB4G1oLCaM-iFCCnpZunNDJPDK-9Mgy0=.9b939992-2f6a-4043-ac65-89432b6e9a87@github.com>

On Tue, 15 Jul 2025 19:11:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this trivial rename of the `clearing_bitmap` member in `G1CollectorState` to align it with the other related ones that read `<something>_in_progress`?
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Looks good and trivial.

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

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26330#pullrequestreview-3022121098

From wkemper at openjdk.org  Tue Jul 15 20:28:19 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 15 Jul 2025 20:28:19 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v3]
In-Reply-To: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
Message-ID: <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>

> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.

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

  Micro optimizations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26256/files
  - new: https://git.openjdk.org/jdk/pull/26256/files/cb63787d..b75574da

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

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

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

From xpeng at openjdk.org  Tue Jul 15 20:49:38 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 15 Jul 2025 20:49:38 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v2]
In-Reply-To: <HojpKpsHMQPsb_NXVY7M_vvOXC8k3N4FjVroT-ZfGno=.822738d8-7bfc-460e-b55f-3df16b6836ca@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
 <CYjxc26_190b82zsRno3GVl-QHmvQw-9W5iCQfqe2Jw=.f1c41a84-ec13-407e-b2a1-dc08e3876c1f@github.com>
 <HojpKpsHMQPsb_NXVY7M_vvOXC8k3N4FjVroT-ZfGno=.822738d8-7bfc-460e-b55f-3df16b6836ca@github.com>
Message-ID: <gxRZ8kc-M8OEE87YoIjjzXN64K58GMcjWhQ3cX5B0wE=.6de5cb35-c36e-4713-b816-b119228460d7@github.com>

On Tue, 15 Jul 2025 07:40:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is another instance of `ShenandoahHeapRegion::required_regions(obj->size() * HeapWordSize);` in `ShenandoahGenerationalHeuristics::choose_collection_set` -- is it affected by the same issue?

I came across the same code recently when I update the choose_collection_set to support CAS for mutator allocation. I was searching and reviewing where ShenandoahHeapRegion::required_regions are used yesterday. There are 9 places where it is been used, out of which only the one in allocation is indeed needed. I was about to create a JBS bug for the improvement.

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

PR Comment: https://git.openjdk.org/jdk/pull/26256#issuecomment-3075559659

From wkemper at openjdk.org  Tue Jul 15 22:34:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 15 Jul 2025 22:34:41 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v3]
In-Reply-To: <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
 <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
Message-ID: <lgIzPbfy1IeWPHvpeEjyjmyhzS5nl3lFcMKIP433cPw=.a90bf6eb-c409-434d-8a51-41c64891230d@github.com>

On Tue, 15 Jul 2025 20:28:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when reclaiming unmarked humongous objects. Prior to this change, the number of regions occupied by a humongous object was computed from the size of the object. To avoid using `oop::size` after class unloading on an unmarked object, Shenandoah now trashes the humongous start region followed by subsequent continuation regions.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Micro optimizations

MacOS test failure looks unrelated (test is running G1).

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

PR Comment: https://git.openjdk.org/jdk/pull/26256#issuecomment-3075947379

From Monica.Beckwith at microsoft.com  Wed Jul 16 00:59:33 2025
From: Monica.Beckwith at microsoft.com (Monica Beckwith)
Date: Wed, 16 Jul 2025 00:59:33 +0000
Subject: RFR 8357445: G1: Time-Based Heap Uncommit During Idle Periods (AHS)
Message-ID: <PH0PR21MB4457237497C26855D72C610BE556A@PH0PR21MB4457.namprd21.prod.outlook.com>

Hi all,

Please review the time-based uncommit during idle periods feature that will help AHS for G1.

**Overview:**?This enhancement introduces a time-based heap uncommit mechanism that operates independently of garbage collection cycles. The implementation tracks region activity using timestamps and proactively uncommits empty memory regions during low-activity periods, providing memory efficiency improvements.

**Key Implementation Points:**
- Background periodic task (G1HeapEvaluationTask) for heap evaluation
- Region-level timestamp tracking in G1HeapRegion
- Conservative algorithm: max 25% of inactive regions or 10% of total regions per evaluation
- VM operation-based uncommitting for thread safety
- Configurable parameters with sensible defaults

**Testing:** I have added 4 comprehensive tests for this feature:?
- TestG1RegionUncommit: Basic uncommit functionality and edge cases
- TestTimeBasedHeapSizing: Overall feature behavior and integration
- TestTimeBasedRegionTracking: Region activity tracking and lifecycle
- TestTimeBasedHeapConfig: Parameter validation and configuration

**Performance Results:** SPECjbb2015 testing shows 34% heap reduction (7168MB ? 4704MB) with minimal performance impact during benchmark runs.

**Links:**
- Changes: https://github.com/openjdk/jdk/pull/26240/files
- Webrev: https://openjdk.github.io/cr/?repo=jdk&pr=26240&range=01
- PR: https://github.com/microsoft/openjdk-workstreams/tree/main/G1-time-based-uncommit
- Issue: https://bugs.openjdk.org/browse/JDK-8357445
- Documentation: https://github.com/microsoft/openjdk-workstreams/tree/main/G1-time-based-uncommit

The documentation includes performance analysis with graphs and comprehensive usage guides.

Thanks,?
Monica

From kbarrett at openjdk.org  Wed Jul 16 05:30:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 16 Jul 2025 05:30:44 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v3]
In-Reply-To: <7IpW5Lli9OZRvPeFnD9aw_WAzL9ZZF0p7_A5ub3joMI=.b77cc0a8-e14c-4de3-8b73-1263aed9bf4d@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <SAyZYkt7EDJDe5SZRM6cLrpYDi1Xog74IyYz5wOvcQU=.3343fbcd-2f09-4af0-8b81-172dd04eb7e4@github.com>
 <059GBakGm5FWdcStuQygNAjbw3JYz_IZ7BXmLcSj4uU=.5be6b8e0-5557-4876-9249-ee25624d41c7@github.com>
 <7IpW5Lli9OZRvPeFnD9aw_WAzL9ZZF0p7_A5ub3joMI=.b77cc0a8-e14c-4de3-8b73-1263aed9bf4d@github.com>
Message-ID: <GLBQdzwS2J-c1P9Dg9pDLnnRWRhqB-vUpX9ylKdY6MU=.e8aed0d0-5c67-4630-bc0c-705f1299c99a@github.com>

On Tue, 15 Jul 2025 08:26:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > Interleaving comments in each place mentioning the missing calls, and an
> > explanatory comment in each place about the overall task would be helpful.
> 
> Added comments.

Sorry, but I'm not finding the new comments especially informative. They seem
like "what" rather than "why" comments. The code seems relatively obvious
about "what". It's the rationale that isn't obvious. Not only about what is
there in each place, but also about what is not.

With the old code, having it all in one place (*) with using-context
controlling the details, that "why" information was implicit but wasn't too
hard to puzzle out. With the proposed scattering that seems much harder (to
me, at least).

Though in the old code the names of the scanning options (and even the name of
the type) aren't all that great. Especially now that option flags are never
combined. (I think there used to be more flags and more detailed control? I
haven't dug through git history to remind myself of how we got here.) If
instead of the scan options we had something like an enum for "young
collection" and "full collection marking" and "full collection pointer
adjustment", I think that would be clearer than the existing code.

To be clear, I'm not dead set against the approach being proposed by this PR.
But such a change needs to be an improvement, and I don't think the current
proposal meets that requirement. Not even compared to the existing code, let
alone compared to tidying things up along the lines described in the previous
paragraph.

(*) The WeakProcessor::oops_do in fullgc pointer adjustment phase is perhaps
an outlier?  Maybe it should have been in process_roots, with a relevant
option? That would have retained the option combining, or perhaps triggered a
move away from that style. Though this also harkens back to a long ago
discussion / dispute about the meaning of "root".

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

PR Comment: https://git.openjdk.org/jdk/pull/26038#issuecomment-3076810608

From tschatzl at openjdk.org  Wed Jul 16 07:04:49 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Jul 2025 07:04:49 GMT
Subject: RFR: 8362271: G1: Improve G1CollectorState::clearing_bitmap name
In-Reply-To: <rdwIiNSKHvgnB4G1oLCaM-iFCCnpZunNDJPDK-9Mgy0=.9b939992-2f6a-4043-ac65-89432b6e9a87@github.com>
References: <9eL7BlKr0k3mx-cZYzE4BiXBqDazMb_0Tpgj_fuoWbA=.3d390fce-90d2-440d-93ab-b2d684688069@github.com>
 <rdwIiNSKHvgnB4G1oLCaM-iFCCnpZunNDJPDK-9Mgy0=.9b939992-2f6a-4043-ac65-89432b6e9a87@github.com>
Message-ID: <gB6vFie5Ix1ZioZIfqJrXOXbd4FLBQoBGLIkMXJzqwA=.8b76c871-e5c8-4d78-ba7c-eae52698cb4e@github.com>

On Tue, 15 Jul 2025 20:05:00 GMT, Sangheon Kim <sangheki at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this trivial rename of the `clearing_bitmap` member in `G1CollectorState` to align it with the other related ones that read `<something>_in_progress`?
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Looks good and trivial.

Thanks @sangheon for your review

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

PR Comment: https://git.openjdk.org/jdk/pull/26330#issuecomment-3077180010

From tschatzl at openjdk.org  Wed Jul 16 07:04:50 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Jul 2025 07:04:50 GMT
Subject: Integrated: 8362271: G1: Improve G1CollectorState::clearing_bitmap
 name
In-Reply-To: <9eL7BlKr0k3mx-cZYzE4BiXBqDazMb_0Tpgj_fuoWbA=.3d390fce-90d2-440d-93ab-b2d684688069@github.com>
References: <9eL7BlKr0k3mx-cZYzE4BiXBqDazMb_0Tpgj_fuoWbA=.3d390fce-90d2-440d-93ab-b2d684688069@github.com>
Message-ID: <gU3Ty7UtirbI_DxZII7dJOcIoas8yCfEW6H27hy7fWM=.158c57c0-ff21-402e-8bda-94bcad78fc8f@github.com>

On Tue, 15 Jul 2025 19:11:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this trivial rename of the `clearing_bitmap` member in `G1CollectorState` to align it with the other related ones that read `<something>_in_progress`?
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 27c58c06
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27c58c06cf2a20db58b41329762f146f984ff440
Stats:     9 lines in 4 files changed: 0 ins; 0 del; 9 mod

8362271: G1: Improve G1CollectorState::clearing_bitmap name

Reviewed-by: sangheki

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

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

From tschatzl at openjdk.org  Wed Jul 16 07:22:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Jul 2025 07:22:45 GMT
Subject: RFR: 8361705: Clean up KlassCleaningTask
In-Reply-To: <Hm2rpOBNLNfYS8RWc9fWpxRPT_AToRoNEDhOX-4uDBw=.ccf1ef8c-6d14-4936-a228-092afa1faf1c@github.com>
References: <Qu6jp4hxprf8zBurCE4slik0aiUEL6g1-j4i2-ayKLM=.180e6ed6-af6e-4b4e-8f48-996057936738@github.com>
 <Hm2rpOBNLNfYS8RWc9fWpxRPT_AToRoNEDhOX-4uDBw=.ccf1ef8c-6d14-4936-a228-092afa1faf1c@github.com>
Message-ID: <VFyjUix6RfV2yBZvrTAfzgG1S3JN4bUv6q0eX6lmA9Y=.d47c6422-eda8-4e7b-9424-33b503da0ef8@github.com>

On Mon, 14 Jul 2025 10:55:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this cleanup of `KlassCleaningTask`, fixing some style issues.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @shipilev for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26289#issuecomment-3077276816

From tschatzl at openjdk.org  Wed Jul 16 07:22:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Jul 2025 07:22:46 GMT
Subject: RFR: 8361705: Clean up KlassCleaningTask
In-Reply-To: <o9PDwwMMztgsNoTNXifTlgU-i8F3rOs2n1FzkRpH-uo=.f4da2518-0bc6-48a2-83c8-993fdb3d8b9a@github.com>
References: <Qu6jp4hxprf8zBurCE4slik0aiUEL6g1-j4i2-ayKLM=.180e6ed6-af6e-4b4e-8f48-996057936738@github.com>
 <o9PDwwMMztgsNoTNXifTlgU-i8F3rOs2n1FzkRpH-uo=.f4da2518-0bc6-48a2-83c8-993fdb3d8b9a@github.com>
Message-ID: <WIhXrmqe7VwaaO-wJWjseZ6YB7567mEejd4GnMZXsDs=.0fb07637-d693-4423-a79f-6fa98b194a90@github.com>

On Mon, 14 Jul 2025 10:16:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this cleanup of `KlassCleaningTask`, fixing some style issues.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/shared/parallelCleaning.cpp line 107:
> 
>> 105:   }
>> 106: 
>> 107:   return !Atomic::cmpxchg(&_clean_klass_tree_claimed, false, true);
> 
> Generally, I prefer to see `Atomic::cmpxchg(&_clean_klass_tree_claimed, false, true) == false`, because `false` here is not about the logical boolean expression, but about the "old" value`false`, which just happens to be a boolean.

I'll ask internally first too, and then fix all of these occurrences at once if needed.

That particular occurrence may go away soon too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26289#discussion_r2209502714

From tschatzl at openjdk.org  Wed Jul 16 07:22:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Jul 2025 07:22:47 GMT
Subject: Integrated: 8361705: Clean up KlassCleaningTask
In-Reply-To: <Qu6jp4hxprf8zBurCE4slik0aiUEL6g1-j4i2-ayKLM=.180e6ed6-af6e-4b4e-8f48-996057936738@github.com>
References: <Qu6jp4hxprf8zBurCE4slik0aiUEL6g1-j4i2-ayKLM=.180e6ed6-af6e-4b4e-8f48-996057936738@github.com>
Message-ID: <dTS_J3pifoGMq240Tj6SthIMBoGD8JPmoD1KMAmIUXM=.75e5eefe-d4cc-4073-a340-5222929c19ef@github.com>

On Mon, 14 Jul 2025 10:06:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this cleanup of `KlassCleaningTask`, fixing some style issues.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: fd2ee084
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd2ee0844a8b96491787c318f2eb6fe4d8fd75c2
Stats:     11 lines in 2 files changed: 1 ins; 6 del; 4 mod

8361705: Clean up KlassCleaningTask

Reviewed-by: shade, ayang

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

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

From shade at openjdk.org  Wed Jul 16 07:58:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Jul 2025 07:58:40 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v3]
In-Reply-To: <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
 <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
Message-ID: <LrcoWwzophiEsBRqIpnr_8Fq92mOSxaRQajYXj4yau8=.b59debfa-18d0-480d-9071-67d641fdcafb@github.com>

On Tue, 15 Jul 2025 20:28:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when reclaiming unmarked humongous objects. Prior to this change, the number of regions occupied by a humongous object was computed from the size of the object. To avoid using `oop::size` after class unloading on an unmarked object, Shenandoah now trashes the humongous start region followed by subsequent continuation regions.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Micro optimizations

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26256#pullrequestreview-3023648512

From tschatzl at openjdk.org  Wed Jul 16 08:28:24 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Jul 2025 08:28:24 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v3]
In-Reply-To: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
Message-ID: <7B9Nf7B04cW2IUoftnexGjyNjvf_gIOG5YiVXlAQlGc=.d50a0051-fe7d-43e7-9c07-9618ae89e1d5@github.com>

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with four additional commits since the last revision:

 - * more refactoring, comments
 - * kbarrett review part 2 (slightly incomplete)
 - * kbarrett review - 1
 - * initial kbarrett refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26189/files
  - new: https://git.openjdk.org/jdk/pull/26189/files/36b023fb..b3a9fea6

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

  Stats: 193 lines in 5 files changed: 106 ins; 56 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/26189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26189/head:pull/26189

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

From tschatzl at openjdk.org  Wed Jul 16 08:34:43 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Jul 2025 08:34:43 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v2]
In-Reply-To: <Emiy2tWaCDTCezsIglV6VWWv66d9yAlMaISFO0L6gy0=.e6367112-5c3f-4a24-b495-89255d4ffffe@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <WjBzjdTZLh9-XBbAgWJL7FmqX_OsrEDKOBD6cqRYTVg=.b9b95d6b-dffe-4375-95a5-2599f5685080@github.com>
 <Emiy2tWaCDTCezsIglV6VWWv66d9yAlMaISFO0L6gy0=.e6367112-5c3f-4a24-b495-89255d4ffffe@github.com>
Message-ID: <aidzXs67uKu4zjBEpNaT2rEElHAI0OnAXkv0YvaT8pI=.2ac5d313-1bf7-4762-b1e2-e86cfb7c189e@github.com>

On Thu, 10 Jul 2025 20:53:17 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * kbarret review:
>>     - restructure code in `try_collect_concurrently`
>>     - fix asserts - they only worked in the test because of whitebox being active
>>     - fix comments
>>   * threalmdoerr review:
>>     - fix test to be more lenient
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1755:
> 
>> 1753:         old_marking_started_before = old_marking_started_after;
>> 1754:       }
>> 1755:     } else if (GCCause::is_codecache_requested_gc(cause) && op.marking_in_progress()) {
> 
> I wonder if this might be simpler if the codecache-request case were
> completely handled by it's own clause. This would involve "duplicating" some
> of the user-request case. But I think that could be done by chunking that into
> a couple helper functions, bounded by the existing assertions in the
> user-request case. So something like this (I don't love the names of the
> helpers here):
> 
> if (is_codecache_requested_gc(cause)) {
>   if (op.marking_in_progress()) {
>     LOG... ;
>     return true;
>   }
>   // is there some assert similar to the user-request assert that makes sense here?
>   if (wait_for_completion(old_marking_started_before,
>                           old_marking_started_after,
>                           old_marking_completed_after)) {
>     return true;
>   }
>   // is there some assert similar to the user-request assert that makes sense here?
>   if (need_normal_retry(op)) {
>     continue;
>   }
> }
> 
> And similarly in the user-request case.  And obviously with more comments :)
> 
> While looking at that, I noticed that the whitebox control stall in the
> user-request case is doing exactly what the comment about it says not to do.
> It is waiting for control to be released, while the comment says not to do
> that. This of course means there could be multiple complete collections (and
> not just STW full collections) before it can proceed. This seems to be in the
> initial published webrev for JDK-8240239. The immediately preceding (draft,
> non-public) webrev has that comment but different code, so it looks like the
> code was changed but the comment wasn't updated. Bad Kim!
> 
> I will file a bug for that and assign it to myself. If you decide to adopt
> something like the above suggested refactoring, just retain that code and
> comment as-is. I'll see if I can recall what happened there, and update the
> comment accordingly. Unfortunately, the (non-public) email discussion between
> those versions doesn't make any mention of this change.

I did the suggested change, the names probably aren't that much better.
Retested tier1-5.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2209668371

From ayang at openjdk.org  Wed Jul 16 09:24:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 16 Jul 2025 09:24:41 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v3]
In-Reply-To: <GLBQdzwS2J-c1P9Dg9pDLnnRWRhqB-vUpX9ylKdY6MU=.e8aed0d0-5c67-4630-bc0c-705f1299c99a@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <SAyZYkt7EDJDe5SZRM6cLrpYDi1Xog74IyYz5wOvcQU=.3343fbcd-2f09-4af0-8b81-172dd04eb7e4@github.com>
 <059GBakGm5FWdcStuQygNAjbw3JYz_IZ7BXmLcSj4uU=.5be6b8e0-5557-4876-9249-ee25624d41c7@github.com>
 <7IpW5Lli9OZRvPeFnD9aw_WAzL9ZZF0p7_A5ub3joMI=.b77cc0a8-e14c-4de3-8b73-1263aed9bf4d@github.com>
 <GLBQdzwS2J-c1P9Dg9pDLnnRWRhqB-vUpX9ylKdY6MU=.e8aed0d0-5c67-4630-bc0c-705f1299c99a@github.com>
Message-ID: <U6tHgZIk_zf8lNbokhfP9WFnM7RAdFo1zuDYH-qpW4A=.d5b623f8-1493-476c-b14a-d8ae510c8f76@github.com>

On Wed, 16 Jul 2025 05:28:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Not only about what is there in each place, but also about what is not.

There are only three kinds of "real" roots -- CLDs, threads, and OopStorage -- and all need to be processed somehow for correctness. In various calling contexts (like young-GC, full-GC marking, or full-GC adjustment), we layer on some additional "pseudo" roots and apply specific closures tailored for those cases. The added comments calls out the additional "pseudo" roots explicitly in every calling context.

I believe this way of structuring the code -- where the handling of roots and pseudo-roots is explicit at each callsite -- results in a simpler and more comprehensible mental model. It avoids the complexity of having a generic method enumerate all possible roots and control the subset for each context via flags or options. Instead, readers can see directly what roots are processed right where it matters.

> But such a change needs to be an improvement...

FWIW, this reveals a redundancy in young-gc root processing: https://github.com/openjdk/jdk/pull/26038#issuecomment-3018419173

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

PR Comment: https://git.openjdk.org/jdk/pull/26038#issuecomment-3077716802

From tschatzl at openjdk.org  Wed Jul 16 09:53:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Jul 2025 09:53:42 GMT
Subject: RFR: 8362278: G1: Consolidate functions for recording pause start
 time
In-Reply-To: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
References: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
Message-ID: <CI7L4BteehGrUYC_BadBEkhu6PRJqZ4e8Lne5pVkyl4=.d21b8fb1-b867-4471-b0f6-7109fd08aea1@github.com>

On Tue, 15 Jul 2025 16:13:34 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi,
> 
> Please review this refactoring change to unify the recording of GC Pause start-time.
> 
> Testing: Tier 1

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1Policy.cpp line 670:

> 668: }
> 669: 
> 670: void G1Policy::record_gc_pause_start_time() {

Could this be named `record_pause_start_time()` which would better correspond to the `record_pause` call at the end of the respective pause?

There is also a kind of mismatch to this name and the `record_cur_collection_start_sec`, which might be more appropriately named `record_cur_pause_start_sec` following this naming.

It's just right now the code uses `gc`, `collection`, `pause` in the names which makes reading a bit harder than necessary.

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

PR Review: https://git.openjdk.org/jdk/pull/26323#pullrequestreview-3024051784
PR Review Comment: https://git.openjdk.org/jdk/pull/26323#discussion_r2209843709

From iwalulya at openjdk.org  Wed Jul 16 10:03:04 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Jul 2025 10:03:04 GMT
Subject: RFR: 8362278: G1: Consolidate functions for recording pause start
 time
In-Reply-To: <CI7L4BteehGrUYC_BadBEkhu6PRJqZ4e8Lne5pVkyl4=.d21b8fb1-b867-4471-b0f6-7109fd08aea1@github.com>
References: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
 <CI7L4BteehGrUYC_BadBEkhu6PRJqZ4e8Lne5pVkyl4=.d21b8fb1-b867-4471-b0f6-7109fd08aea1@github.com>
Message-ID: <tcDw-clhbxvpdTEkfGua-6y7zDUE7VziUdbNf7NsPnU=.d8b22e78-3a5d-4738-90c0-a4b8245b6b68@github.com>

On Wed, 16 Jul 2025 09:51:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this refactoring change to unify the recording of GC Pause start-time.
>> 
>> Testing: Tier 1
>
> src/hotspot/share/gc/g1/g1Policy.cpp line 670:
> 
>> 668: }
>> 669: 
>> 670: void G1Policy::record_gc_pause_start_time() {
> 
> Could this be named `record_pause_start_time()` which would better correspond to the `record_pause` call at the end of the respective pause?
> 
> There is also a kind of mismatch to this name and the `record_cur_collection_start_sec`, which might be more appropriately named `record_cur_pause_start_sec` following this naming.
> 
> It's just right now the code uses `gc`, `collection`, `pause` in the names which makes reading a bit harder than necessary.

True, in the first commit I had it as `record_pause_start_time`. Let change both

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26323#discussion_r2209863514

From iwalulya at openjdk.org  Wed Jul 16 10:21:55 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Jul 2025 10:21:55 GMT
Subject: RFR: 8362278: G1: Consolidate functions for recording pause start
 time [v2]
In-Reply-To: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
References: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
Message-ID: <eMZ0xqQfq2UITwqu1YPz5v9ODyIdsmfen9N1excuNNk=.0966b7a2-3259-4b89-b7bc-18bf64ecf310@github.com>

> Hi,
> 
> Please review this refactoring change to unify the recording of GC Pause start-time.
> 
> Testing: Tier 1

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

  Thomas Review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26323/files
  - new: https://git.openjdk.org/jdk/pull/26323/files/6094a16c..f5ed7d19

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

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

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

From iwalulya at openjdk.org  Wed Jul 16 11:24:04 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Jul 2025 11:24:04 GMT
Subject: RFR: 8362278: G1: Consolidate functions for recording pause start
 time [v3]
In-Reply-To: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
References: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
Message-ID: <FLm9XpjTu1JrMiSWgKwMgdAsEU-2QVg5O3cgSYrz4EU=.47a93304-2d58-4e7a-9d06-b84f55a9306b@github.com>

> Hi,
> 
> Please review this refactoring change to unify the recording of GC Pause start-time.
> 
> Testing: Tier 1

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

  Thomas suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26323/files
  - new: https://git.openjdk.org/jdk/pull/26323/files/f5ed7d19..7d3ea11e

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

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

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

From tschatzl at openjdk.org  Wed Jul 16 12:24:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Jul 2025 12:24:46 GMT
Subject: RFR: 8362278: G1: Consolidate functions for recording pause start
 time [v3]
In-Reply-To: <FLm9XpjTu1JrMiSWgKwMgdAsEU-2QVg5O3cgSYrz4EU=.47a93304-2d58-4e7a-9d06-b84f55a9306b@github.com>
References: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
 <FLm9XpjTu1JrMiSWgKwMgdAsEU-2QVg5O3cgSYrz4EU=.47a93304-2d58-4e7a-9d06-b84f55a9306b@github.com>
Message-ID: <lvqHXFL4otesNhSf9kQxJ0SbbkSQBG0I8vZsmkn9nSc=.e9a18a2a-9beb-409d-8e84-560ca9186b7c@github.com>

On Wed, 16 Jul 2025 11:24:04 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this refactoring change to unify the recording of GC Pause start-time.
>> 
>> Testing: Tier 1
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas suggestion

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26323#pullrequestreview-3024662802

From ayang at openjdk.org  Wed Jul 16 12:33:47 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 16 Jul 2025 12:33:47 GMT
Subject: RFR: 8362278: G1: Consolidate functions for recording pause start
 time [v3]
In-Reply-To: <FLm9XpjTu1JrMiSWgKwMgdAsEU-2QVg5O3cgSYrz4EU=.47a93304-2d58-4e7a-9d06-b84f55a9306b@github.com>
References: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
 <FLm9XpjTu1JrMiSWgKwMgdAsEU-2QVg5O3cgSYrz4EU=.47a93304-2d58-4e7a-9d06-b84f55a9306b@github.com>
Message-ID: <WOGVMr2ZxMrCM9jcPXmOdtzixeSLRGtG4TIuaeK1n6M=.663d8d18-f2be-40d7-a1bb-d8cd63bcea9f@github.com>

On Wed, 16 Jul 2025 11:24:04 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this refactoring change to unify the recording of GC Pause start-time.
>> 
>> Testing: Tier 1
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas suggestion

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26323#pullrequestreview-3024692885

From duke at openjdk.org  Wed Jul 16 13:23:52 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Jul 2025 13:23:52 GMT
Subject: Withdrawn: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics
In-Reply-To: <P66sr7SEFnvxMzuik_GCVKQVlkxA8WvL_TQnQQkR8ME=.4c76d923-087d-47f1-b292-85598a584902@github.com>
References: <P66sr7SEFnvxMzuik_GCVKQVlkxA8WvL_TQnQQkR8ME=.4c76d923-087d-47f1-b292-85598a584902@github.com>
Message-ID: <wxsXPUY294vvJeIJvUGSRwg0nDm4NsSAwjyeBJtXy38=.250d7a4f-27da-4b4c-b307-9b3bad32560f@github.com>

On Mon, 24 Mar 2025 23:07:08 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> I have implemented SoftMaxHeapSize for G1 as attached. It is completely reworked compared to [previous PR](https://github.com/openjdk/jdk/pull/20783), and excludes code for `CurrentMaxHeapSize`. I believe I have addressed all direct concerns from [previous email thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050214.html), such as:
> 
> - does not respect `MinHeapSize`;
> - being too "blunt" and does not respect other G1 heuristics and flags for resizing, such as `MinHeapFreeRatio`, `MaxHeapFreeRatio`;
> - does not affect heuristcs to trigger a concurrent cycle;
> 
> [This recent thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-March/051619.html) also has some context.

This pull request has been closed without being integrated.

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

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

From iwalulya at openjdk.org  Wed Jul 16 14:36:21 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Jul 2025 14:36:21 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
Message-ID: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>

Hi,

Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included.

With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing.  Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios.

Testing: Tier 1

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

Depends on: https://git.openjdk.org/jdk/pull/26323

Commit messages:
 - Merge branch 'NormalizeTiming' into ConcCPUImpact
 - reorder
 - concurrent gc impact

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

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

From wkemper at openjdk.org  Wed Jul 16 17:33:45 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 16 Jul 2025 17:33:45 GMT
Subject: Integrated: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated
In-Reply-To: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
Message-ID: <xApLA3dNvlFYej-20BihRAL-ySv0aHRlRUMGUOw5XOY=.fa43ad69-d011-4d95-8705-06dd56929af6@github.com>

On Thu, 10 Jul 2025 22:20:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when reclaiming unmarked humongous objects. Prior to this change, the number of regions occupied by a humongous object was computed from the size of the object. To avoid using `oop::size` after class unloading on an unmarked object, Shenandoah now trashes the humongous start region followed by subsequent continuation regions.

This pull request has now been integrated.

Changeset: 3b44d7bf
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b44d7bfa4d78e3ec715fce1863e052852f33180
Stats:     20 lines in 2 files changed: 3 ins; 7 del; 10 mod

8360288: Shenandoah crash at size_given_klass in op_degenerated

Reviewed-by: shade

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

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

From shade at openjdk.org  Wed Jul 16 17:42:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Jul 2025 17:42:54 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v3]
In-Reply-To: <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
 <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
Message-ID: <TFtRHAcCD28oB7tjryZZF7HVVczS1RTA4zOyIK1Fgy4=.c106df3e-f772-4a4e-a0ce-aed2d12657c9@github.com>

On Tue, 15 Jul 2025 20:28:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when reclaiming unmarked humongous objects. Prior to this change, the number of regions occupied by a humongous object was computed from the size of the object. To avoid using `oop::size` after class unloading on an unmarked object, Shenandoah now trashes the humongous start region followed by subsequent continuation regions.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Micro optimizations

Haven't I requested to change the synopsis here? https://github.com/openjdk/jdk/pull/26256#pullrequestreview-3021951860 https://github.com/openjdk/jdk/pull/26256#pullrequestreview-3019102674

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

PR Comment: https://git.openjdk.org/jdk/pull/26256#issuecomment-3079602668

From wkemper at openjdk.org  Wed Jul 16 17:53:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 16 Jul 2025 17:53:55 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v3]
In-Reply-To: <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
 <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
Message-ID: <qZ0hsMVgeqM_Yar_QBxsi7qUodw4Vr7yT6s_98yGN9M=.4a85f2d1-d0b8-4d4c-95fb-e92b6106247f@github.com>

On Tue, 15 Jul 2025 20:28:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when reclaiming unmarked humongous objects. Prior to this change, the number of regions occupied by a humongous object was computed from the size of the object. To avoid using `oop::size` after class unloading on an unmarked object, Shenandoah now trashes the humongous start region followed by subsequent continuation regions.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Micro optimizations

My apologies. Some confusion over which field you expected me to update.

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

PR Comment: https://git.openjdk.org/jdk/pull/26256#issuecomment-3079658769

From shade at openjdk.org  Wed Jul 16 18:09:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Jul 2025 18:09:45 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated [v3]
In-Reply-To: <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
 <oYEKHmE9uNN99I6O8nvac75nsP4bwMkdZhKr61GViDQ=.c9e4e326-5ce2-41d7-a542-c904a98c713c@github.com>
Message-ID: <5QX-QwvvnVyvMawrWOm6UVtfozIBPkuL8DRIijNmOJk=.f3728410-7e0a-4e4e-a300-3d755c351e59@github.com>

On Tue, 15 Jul 2025 20:28:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when reclaiming unmarked humongous objects. Prior to this change, the number of regions occupied by a humongous object was computed from the size of the object. To avoid using `oop::size` after class unloading on an unmarked object, Shenandoah now trashes the humongous start region followed by subsequent continuation regions.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Micro optimizations

Yeah, no big deal, just not a great commit message :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26256#issuecomment-3079715774

From wkemper at openjdk.org  Wed Jul 16 18:10:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 16 Jul 2025 18:10:50 GMT
Subject: [jdk25] RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated
Message-ID: <iJ7vJLthvf5aeNb-b9hwFib-WOl81gB7quOBmLKa_xQ=.f6031290-3a25-4343-beb4-69fe68fc64d6@github.com>

Clean backport. Fixes a crash in Shenandoah (ILW = P3). Only touches Shenandoah code.

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

Commit messages:
 - Backport 3b44d7bfa4d78e3ec715fce1863e052852f33180

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

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

From shade at openjdk.org  Wed Jul 16 18:10:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Jul 2025 18:10:50 GMT
Subject: [jdk25] RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated
In-Reply-To: <iJ7vJLthvf5aeNb-b9hwFib-WOl81gB7quOBmLKa_xQ=.f6031290-3a25-4343-beb4-69fe68fc64d6@github.com>
References: <iJ7vJLthvf5aeNb-b9hwFib-WOl81gB7quOBmLKa_xQ=.f6031290-3a25-4343-beb4-69fe68fc64d6@github.com>
Message-ID: <i3eV_XGj61ttYJgCh6QwmNPa6DM45gbCaF68ZpBQ410=.067f29d9-8a7c-4192-ac3a-e1c208119b20@github.com>

On Wed, 16 Jul 2025 18:04:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes a crash in Shenandoah (ILW = P3). Only touches Shenandoah code.

Makes sense for JDK 25.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26356#pullrequestreview-3026234758

From iwalulya at openjdk.org  Wed Jul 16 18:46:47 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Jul 2025 18:46:47 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
Message-ID: <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>

On Thu, 10 Jul 2025 18:09:17 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
>> 
>> Implement time-based heap uncommit for G1 during idle periods.
>> 
>> Key changes:
>> - Added G1HeapEvaluationTask for periodic heap evaluation
>> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
>> - Implemented time-based heap sizing policy with configurable uncommit delay
>> - Added region activity tracking with last access timestamps
>> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
>> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
>> - Added 'sizing' log tag for heap sizing operations
>> 
>> Comprehensive Test Coverage:
>> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
>> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
>> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
>> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
>> 
>> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Normalize encoding and line endings for G1 GC time-based tests

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/g1/g1Allocator.hpp line 35:

> 33: class G1EvacInfo;
> 34: class G1NUMA;
> 35: class G1HeapSizingPolicy;

Probably not required here

src/hotspot/share/gc/g1/g1Allocator.inline.hpp line 61:

> 59:   }
> 60: 
> 61:   return result;

If this needs to be made, it should be done as a separate cleanup as it is not related to the CR.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1:

> 1: ?

Extra line should be removed

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 43:

> 41: #include "gc/g1/g1ConcurrentRefineThread.hpp"
> 42: #include "gc/g1/g1HeapSizingPolicy.hpp"  // Include this first to avoid include cycle
> 43: #include "gc/g1/g1HeapEvaluationTask.hpp"

cycles cannot happen because we have the `#ifndef` for the .hpp files

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1078:

> 1076:                            shrink_bytes, shrunk_bytes, num_regions_removed);
> 1077:   if (num_regions_removed > 0) {
> 1078:     log_info(gc, heap)("Heap shrink completed: uncommitted %u regions (%zuMB), heap size now %zuMB",

At this point, we have flagged regions for uncommitting, but no guarantee that these regions have been uncommitted. The log entry might be confusing if we indicate that shrinking is completed, and yet NMT indicates otherwise.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1511:

> 1509:     log_debug(gc, init)("G1 Time-Based Heap Evaluation task created (PeriodicTask)");
> 1510:   } else {
> 1511:     _heap_evaluation_task = nullptr;

maybe replace with an `assert(_heap_evaluation_task == nullptr, "pre-condition");`

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1511:

> 1509:     log_debug(gc, init)("G1 Time-Based Heap Evaluation task created (PeriodicTask)");
> 1510:   } else {
> 1511:     _heap_evaluation_task = nullptr;

Suggestion:

    assert(_heap_evaluation_task == nullptr, "pre-condition")

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1575:

> 1573: 
> 1574:   // Enroll the heap evaluation task after G1 is fully initialized
> 1575:   if (G1UseTimeBasedHeapSizing && _heap_evaluation_task != nullptr) {

any reason why `_heap_evaluation_task == nullptr` could be `true` if `G1UseTimeBasedHeapSizing` is `true`?

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2962:

> 2960:   assert(alloc_region->is_eden(), "all mutator alloc regions should be eden");
> 2961: 
> 2962:   alloc_region->record_activity();  // Record the activity of the alloc region

Since we only uncommit free regions, we only need to `record_activity` when the region is freed which is done in `G1HeapRegion::hr_clear` before the region is added to the free-list

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1:

> 1: 

Extra black line, please delete.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 931:

> 929:   G1Policy* policy() const { return _policy; }
> 930:   // The heap sizing policy.
> 931:   G1HeapSizingPolicy* heap_sizing_policy() const { return _heap_sizing_policy; }

unused method, probably not needed.

src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 36:

> 34: #include "utilities/globalDefinitions.hpp"
> 35: 
> 36: G1HeapEvaluationTask::G1HeapEvaluationTask(G1CollectedHeap* g1h, G1HeapSizingPolicy* heap_sizing_policy) :

`G1HeapEvaluationTask` class name does not seem to clearly state the purpose of the class. But I cannot come up with a better name.

src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 44:

> 42: void G1HeapEvaluationTask::task() {
> 43:   // This runs on WatcherThread during idle periods - perfect for time-based evaluation!
> 44:   log_debug(gc, sizing)("Starting heap evaluation");

For existing Heap Resizing tasks, we use the tags `(gc, ergo, heap)`, I would suggest we maintain that.

src/hotspot/share/gc/g1/g1HeapEvaluationTask.hpp line 35:

> 33: 
> 34: // Time-based heap evaluation task that runs during idle periods
> 35: class G1HeapEvaluationTask : public PeriodicTask {  // Changed from G1ServiceTask

Add a comment explaining why we use `PeriodicTask`  instead of  `G1ServiceTask`

Then the comments on ` // Changed from g1ServiceThread.hpp` and `// Changed from execute() to task()` will not be required

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

> 44: void G1HeapSizingPolicy::initialize() {
> 45:   // Flag values are available at this point
> 46:   _uncommit_delay_ms = (jlong)G1UncommitDelayMillis;

I think we can "safely" do this in the constructor for G1HeapSizingPolicy, then we don't need the `initialize` method. 

We also do not need to make `_uncommit_delay_ms`, `G1HeapSizingPolicy` relies on the singleton pattern through `G1HeapSizingPolicy::create`.

src/hotspot/share/runtime/vmOperations.cpp line 649:

> 647: }
> 648: #endif // INCLUDE_G1GC
> 649: 

Please move to `g1VMOperations.cpp`

src/hotspot/share/runtime/vmOperations.hpp line 308:

> 306:   bool is_gc_operation() const override { return true; }
> 307:   void doit() override;
> 308: };

Should be moved to `g1VMOperations.hpp`

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

PR Review: https://git.openjdk.org/jdk/pull/26240#pullrequestreview-3025735357
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2210888250
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2210859827
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2210910763
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2210862304
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2210920641
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211025677
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211027979
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211045517
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211237408
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2210904505
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2210908900
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211257389
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211254835
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2210937453
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211010976
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211278259
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211268097

From mbeckwit at openjdk.org  Wed Jul 16 20:52:25 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Wed, 16 Jul 2025 20:52:25 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
Message-ID: <6tGL2PHITH0ok_qunRGR_EojSnJuPLX5ZLaw7ZeJeRU=.95af9d2a-7e2e-45b0-b72d-ede91adaadc4@github.com>

On Wed, 16 Jul 2025 18:27:14 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> For existing Heap Resizing tasks, we use the tags `(gc, ergo, heap)`, I would suggest we maintain that.

I'd like to discuss the logging tag choice. While I understand the consistency argument for using (gc,ergo,heap), I believe (gc,sizing) is more appropriate here because:

1. This is a distinct sizing mechanism, not traditional ergonomic heap management
2. Users troubleshooting time-based sizing specifically will benefit from a dedicated tag
3. It aligns with the feature name and purpose
4. It provides better separation of concerns for logging

Would you be open to keeping (gc,sizing) for semantic clarity?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211580151

From mbeckwit at openjdk.org  Wed Jul 16 21:13:52 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Wed, 16 Jul 2025 21:13:52 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
Message-ID: <jhm8UOGCEy3uikTconMCVSYoI8U9ZG7qObNES6-3Fq0=.15756a0b-5e5c-4d85-a029-ecea559d8a1e@github.com>

On Wed, 16 Jul 2025 18:20:30 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Normalize encoding and line endings for G1 GC time-based tests
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2962:
> 
>> 2960:   assert(alloc_region->is_eden(), "all mutator alloc regions should be eden");
>> 2961: 
>> 2962:   alloc_region->record_activity();  // Record the activity of the alloc region
> 
> Since we only uncommit free regions, we only need to `record_activity` when the region is freed which is done in `G1HeapRegion::hr_clear` before the region is added to the free-list

Thanks for pointing this out?you're right, and to clarify, the logic explicitly ensures that we only ever uncommit free regions. When I designed this, I tracked both allocation activities and retirements to record region idle times as accurately and minimally as possible.

For precise time-based tracking, I believe we need to update the timestamp at both `hr_clear()` and retirement. Here?s the timing consideration:

**The timing issue:**
1. Region cleared ? `hr_clear()` ? `record_activity()` ? sets timestamp = T1
2. Region is allocated and used for extended period
3. Region is retired ? if we only update the timestamp at clear, not at retirement, there?s no new timestamp
4. Time-based evaluation ? sees timestamp T1 (from clear, not retire)
5. Result: Region appears "idle" since T1, even though it was just recently retired

So, we need `record_activity()` at both lifecycle points:

- **`hr_clear()`**: When a region becomes available (initialization)
- **`retire_*()`**: When a region finishes active use (retirement)

This way we always track the **most recent activity** for each region, whether that was clearing or retirement, giving us accurate idle time calculations for time-based uncommit decisions.

Since the logic guarantees we only uncommit regions that are truly free and have been idle for the configured delay, having an accurate ?last active? timestamp is critical for the feature?s effectiveness.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211619736

From iwalulya at openjdk.org  Wed Jul 16 21:13:53 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Jul 2025 21:13:53 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <6tGL2PHITH0ok_qunRGR_EojSnJuPLX5ZLaw7ZeJeRU=.95af9d2a-7e2e-45b0-b72d-ede91adaadc4@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
 <6tGL2PHITH0ok_qunRGR_EojSnJuPLX5ZLaw7ZeJeRU=.95af9d2a-7e2e-45b0-b72d-ede91adaadc4@github.com>
Message-ID: <afYpHnOffnW2fT4FmjHeElzjWnHQrS_OONa7qak-VjI=.555b08c8-40c3-4029-b03b-736ff3ccfcbf@github.com>

On Wed, 16 Jul 2025 20:49:30 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 44:
>> 
>>> 42: void G1HeapEvaluationTask::task() {
>>> 43:   // This runs on WatcherThread during idle periods - perfect for time-based evaluation!
>>> 44:   log_debug(gc, sizing)("Starting heap evaluation");
>> 
>> For existing Heap Resizing tasks, we use the tags `(gc, ergo, heap)`, I would suggest we maintain that.
>
>> For existing Heap Resizing tasks, we use the tags `(gc, ergo, heap)`, I would suggest we maintain that.
> 
> I'd like to discuss the logging tag choice. While I understand the consistency argument for using (gc,ergo,heap), I believe (gc,sizing) is more appropriate here because:
> 
> 1. This is a distinct sizing mechanism, not traditional ergonomic heap management
> 2. Users troubleshooting time-based sizing specifically will benefit from a dedicated tag
> 3. It aligns with the feature name and purpose
> 4. It provides better separation of concerns for logging
> 
> Would you be open to keeping (gc,sizing) for semantic clarity?

My argument is related to consistency, if there are reasons to have this logging distinct from the `(gc, ergo, heap)`, that is fine by me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211618240

From iwalulya at openjdk.org  Wed Jul 16 21:27:47 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Jul 2025 21:27:47 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <jhm8UOGCEy3uikTconMCVSYoI8U9ZG7qObNES6-3Fq0=.15756a0b-5e5c-4d85-a029-ecea559d8a1e@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
 <jhm8UOGCEy3uikTconMCVSYoI8U9ZG7qObNES6-3Fq0=.15756a0b-5e5c-4d85-a029-ecea559d8a1e@github.com>
Message-ID: <uvdfWzTObWKnhxyfupTjoKEPVNNMuBHVOKmLKA_9aY8=.b1fe600d-74d8-49da-9e7f-61c8f830ef99@github.com>

On Wed, 16 Jul 2025 21:10:41 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2962:
>> 
>>> 2960:   assert(alloc_region->is_eden(), "all mutator alloc regions should be eden");
>>> 2961: 
>>> 2962:   alloc_region->record_activity();  // Record the activity of the alloc region
>> 
>> Since we only uncommit free regions, we only need to `record_activity` when the region is freed which is done in `G1HeapRegion::hr_clear` before the region is added to the free-list
>
> Thanks for pointing this out?you're right, and to clarify, the logic explicitly ensures that we only ever uncommit free regions. When I designed this, I tracked both allocation activities and retirements to record region idle times as accurately and minimally as possible.
> 
> For precise time-based tracking, I believe we need to update the timestamp at both `hr_clear()` and retirement. Here?s the timing consideration:
> 
> **The timing issue:**
> 1. Region cleared ? `hr_clear()` ? `record_activity()` ? sets timestamp = T1
> 2. Region is allocated and used for extended period
> 3. Region is retired ? if we only update the timestamp at clear, not at retirement, there?s no new timestamp
> 4. Time-based evaluation ? sees timestamp T1 (from clear, not retire)
> 5. Result: Region appears "idle" since T1, even though it was just recently retired
> 
> So, we need `record_activity()` at both lifecycle points:
> 
> - **`hr_clear()`**: When a region becomes available (initialization)
> - **`retire_*()`**: When a region finishes active use (retirement)
> 
> This way we always track the **most recent activity** for each region, whether that was clearing or retirement, giving us accurate idle time calculations for time-based uncommit decisions.
> 
> Since the logic guarantees we only uncommit regions that are truly free and have been idle for the configured delay, having an accurate ?last active? timestamp is critical for the feature?s effectiveness.

IIUC `retire` a region means that the region has been retired from allocation, however, the particular region is in active use just that we can no longer allocate out of this region. Eventually, this region will be evacuated and `hr_clear()` called. So `record_activity()` during retirement is redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211639765

From iwalulya at openjdk.org  Wed Jul 16 21:27:48 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Jul 2025 21:27:48 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <uvdfWzTObWKnhxyfupTjoKEPVNNMuBHVOKmLKA_9aY8=.b1fe600d-74d8-49da-9e7f-61c8f830ef99@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
 <jhm8UOGCEy3uikTconMCVSYoI8U9ZG7qObNES6-3Fq0=.15756a0b-5e5c-4d85-a029-ecea559d8a1e@github.com>
 <uvdfWzTObWKnhxyfupTjoKEPVNNMuBHVOKmLKA_9aY8=.b1fe600d-74d8-49da-9e7f-61c8f830ef99@github.com>
Message-ID: <bFrIxEpwYhn5nSJPTydTK2ODo-ShDmkHqe9mI5vTW3g=.177e7583-8f97-4646-a25f-fcd573442b09@github.com>

On Wed, 16 Jul 2025 21:23:11 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Thanks for pointing this out?you're right, and to clarify, the logic explicitly ensures that we only ever uncommit free regions. When I designed this, I tracked both allocation activities and retirements to record region idle times as accurately and minimally as possible.
>> 
>> For precise time-based tracking, I believe we need to update the timestamp at both `hr_clear()` and retirement. Here?s the timing consideration:
>> 
>> **The timing issue:**
>> 1. Region cleared ? `hr_clear()` ? `record_activity()` ? sets timestamp = T1
>> 2. Region is allocated and used for extended period
>> 3. Region is retired ? if we only update the timestamp at clear, not at retirement, there?s no new timestamp
>> 4. Time-based evaluation ? sees timestamp T1 (from clear, not retire)
>> 5. Result: Region appears "idle" since T1, even though it was just recently retired
>> 
>> So, we need `record_activity()` at both lifecycle points:
>> 
>> - **`hr_clear()`**: When a region becomes available (initialization)
>> - **`retire_*()`**: When a region finishes active use (retirement)
>> 
>> This way we always track the **most recent activity** for each region, whether that was clearing or retirement, giving us accurate idle time calculations for time-based uncommit decisions.
>> 
>> Since the logic guarantees we only uncommit regions that are truly free and have been idle for the configured delay, having an accurate ?last active? timestamp is critical for the feature?s effectiveness.
>
> IIUC `retire` a region means that the region has been retired from allocation, however, the particular region is in active use just that we can no longer allocate out of this region. Eventually, this region will be evacuated and `hr_clear()` called. So `record_activity()` during retirement is redundant.

`hr_clear` is called when the region is freed in `G1CollectedHeap::free_region`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211642757

From mbeckwit at openjdk.org  Wed Jul 16 21:50:51 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Wed, 16 Jul 2025 21:50:51 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
Message-ID: <Ny2TNW-yZD1dZUVZBsmhVJyMe-J0p5oFLzi7GOV6eYI=.2fde56d9-17aa-4a23-9100-1e8dc6007d98@github.com>

On Wed, 16 Jul 2025 16:16:19 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Normalize encoding and line endings for G1 GC time-based tests
>
> src/hotspot/share/gc/g1/g1Allocator.hpp line 35:
> 
>> 33: class G1EvacInfo;
>> 34: class G1NUMA;
>> 35: class G1HeapSizingPolicy;
> 
> Probably not required here

removed

> src/hotspot/share/gc/g1/g1Allocator.inline.hpp line 61:
> 
>> 59:   }
>> 60: 
>> 61:   return result;
> 
> If this needs to be made, it should be done as a separate cleanup as it is not related to the CR.

sounds good, will revert.

> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1:
> 
>> 1: ?
> 
> Extra line should be removed

removed

> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 43:
> 
>> 41: #include "gc/g1/g1ConcurrentRefineThread.hpp"
>> 42: #include "gc/g1/g1HeapSizingPolicy.hpp"  // Include this first to avoid include cycle
>> 43: #include "gc/g1/g1HeapEvaluationTask.hpp"
> 
> cycles cannot happen because we have the `#ifndef` for the .hpp files

fixed and removed comment

> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1078:
> 
>> 1076:                            shrink_bytes, shrunk_bytes, num_regions_removed);
>> 1077:   if (num_regions_removed > 0) {
>> 1078:     log_info(gc, heap)("Heap shrink completed: uncommitted %u regions (%zuMB), heap size now %zuMB",
> 
> At this point, we have flagged regions for uncommitting, but no guarantee that these regions have been uncommitted. The log entry might be confusing if we indicate that shrinking is completed, and yet NMT indicates otherwise.

changed to "flagged"

> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1511:
> 
>> 1509:     log_debug(gc, init)("G1 Time-Based Heap Evaluation task created (PeriodicTask)");
>> 1510:   } else {
>> 1511:     _heap_evaluation_task = nullptr;
> 
> maybe replace with an `assert(_heap_evaluation_task == nullptr, "pre-condition");`

replaced with assert

> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1575:
> 
>> 1573: 
>> 1574:   // Enroll the heap evaluation task after G1 is fully initialized
>> 1575:   if (G1UseTimeBasedHeapSizing && _heap_evaluation_task != nullptr) {
> 
> any reason why `_heap_evaluation_task == nullptr` could be `true` if `G1UseTimeBasedHeapSizing` is `true`?

fixed - when G1UseTimeBasedHeapSizing is true, _heap_evaluation_task is created in the constructor, so it should never be nullptr in post_initialize()

> src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1:
> 
>> 1: 
> 
> Extra black line, please delete.

removed

> src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 931:
> 
>> 929:   G1Policy* policy() const { return _policy; }
>> 930:   // The heap sizing policy.
>> 931:   G1HeapSizingPolicy* heap_sizing_policy() const { return _heap_sizing_policy; }
> 
> unused method, probably not needed.

removed

> src/hotspot/share/gc/g1/g1HeapEvaluationTask.hpp line 35:
> 
>> 33: 
>> 34: // Time-based heap evaluation task that runs during idle periods
>> 35: class G1HeapEvaluationTask : public PeriodicTask {  // Changed from G1ServiceTask
> 
> Add a comment explaining why we use `PeriodicTask`  instead of  `G1ServiceTask`
> 
> Then the comments on ` // Changed from g1ServiceThread.hpp` and `// Changed from execute() to task()` will not be required

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211670618
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211671247
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211671414
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211671927
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211672028
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211672215
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211674671
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211674803
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211674926
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211675423

From mbeckwit at openjdk.org  Wed Jul 16 22:04:50 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Wed, 16 Jul 2025 22:04:50 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
Message-ID: <hCj5Vg4jsfQ5O5NAJgmrorIjDHSxa3OPoptK0z0zcUA=.75f588f6-61bd-4543-9213-930dd6b0a075@github.com>

On Wed, 16 Jul 2025 18:28:33 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Normalize encoding and line endings for G1 GC time-based tests
>
> src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 36:
> 
>> 34: #include "utilities/globalDefinitions.hpp"
>> 35: 
>> 36: G1HeapEvaluationTask::G1HeapEvaluationTask(G1CollectedHeap* g1h, G1HeapSizingPolicy* heap_sizing_policy) :
> 
> `G1HeapEvaluationTask` class name does not seem to clearly state the purpose of the class. But I cannot come up with a better name.

I can see that while 'G1HeapEvaluationTask' is generic, it kind of does describe what the class does (evaluates heap sizing decisions). The time-based nature is captured in the feature flag and comments. Open to suggestions if you have a preference.

> src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 46:
> 
>> 44: void G1HeapSizingPolicy::initialize() {
>> 45:   // Flag values are available at this point
>> 46:   _uncommit_delay_ms = (jlong)G1UncommitDelayMillis;
> 
> I think we can "safely" do this in the constructor for G1HeapSizingPolicy, then we don't need the `initialize` method. 
> 
> We also do not need to make `_uncommit_delay_ms`, `G1HeapSizingPolicy` relies on the singleton pattern through `G1HeapSizingPolicy::create`.

Good point! You're absolutely right - since G1HeapSizingPolicy uses the singleton pattern through `create()`, we can safely move the initialization into the constructor and eliminate the separate `initialize()` method. Made the change:

- Moved `_uncommit_delay_ms` initialization into the constructor
- Removed the `initialize()` method
- Removed the call to `initialize()` from G1CollectedHeap constructor

Much cleaner approach, thanks for the suggestion!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211693780
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211696018

From mbeckwit at openjdk.org  Wed Jul 16 22:11:52 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Wed, 16 Jul 2025 22:11:52 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
Message-ID: <_7Ni5B7Q9aSTYy2Mkm72AMiX2WkuykhdotAmnlBFXdY=.d091037c-9ad7-4700-996c-a704af69f253@github.com>

On Wed, 16 Jul 2025 18:40:14 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Normalize encoding and line endings for G1 GC time-based tests
>
> src/hotspot/share/runtime/vmOperations.cpp line 649:
> 
>> 647: }
>> 648: #endif // INCLUDE_G1GC
>> 649: 
> 
> Please move to `g1VMOperations.cpp`

Good suggestion! Moved `VM_G1ShrinkHeap::doit()` implementation from `vmOperations.cpp` to `g1VMOperations.cpp` where it belongs with the other G1-specific VM operations. Much better organization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211705285

From mbeckwit at openjdk.org  Wed Jul 16 22:52:49 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Wed, 16 Jul 2025 22:52:49 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
Message-ID: <bF5vhGX8W3fUBTkl9sT6ieb3dXZ2U0Vta_hEcJM7JMY=.ab5bac18-47c0-4489-9aee-6226a846018c@github.com>

On Wed, 16 Jul 2025 18:34:22 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Normalize encoding and line endings for G1 GC time-based tests
>
> src/hotspot/share/runtime/vmOperations.hpp line 308:
> 
>> 306:   bool is_gc_operation() const override { return true; }
>> 307:   void doit() override;
>> 308: };
> 
> Should be moved to `g1VMOperations.hpp`

done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211766105

From mbeckwit at openjdk.org  Thu Jul 17 01:13:42 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 17 Jul 2025 01:13:42 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v3]
In-Reply-To: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
Message-ID: <9aiRIn5323HgYmeLs_d3dxfRNgXr4EZQDJDJsmuwhM8=.48173e35-654b-44c8-8808-3670bc0b691f@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

  8357445: Address code review feedback
  
  Extra line removed
  Include cycle comment removed
  completed changed to flagged
  nullptr assignment changed to assert
  Redundant nullptr check removed
  VM_G1ShrinkHeap moved
  Forward declaration removed
  Constructor initialization for static _uncommit_delay_ms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26240/files
  - new: https://git.openjdk.org/jdk/pull/26240/files/70a872fc..8897a2b0

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

  Stats: 69 lines in 12 files changed: 26 ins; 32 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240

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

From mbeckwit at openjdk.org  Thu Jul 17 01:40:49 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 17 Jul 2025 01:40:49 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <bFrIxEpwYhn5nSJPTydTK2ODo-ShDmkHqe9mI5vTW3g=.177e7583-8f97-4646-a25f-fcd573442b09@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
 <jhm8UOGCEy3uikTconMCVSYoI8U9ZG7qObNES6-3Fq0=.15756a0b-5e5c-4d85-a029-ecea559d8a1e@github.com>
 <uvdfWzTObWKnhxyfupTjoKEPVNNMuBHVOKmLKA_9aY8=.b1fe600d-74d8-49da-9e7f-61c8f830ef99@github.com>
 <bFrIxEpwYhn5nSJPTydTK2ODo-ShDmkHqe9mI5vTW3g=.177e7583-8f97-4646-a25f-fcd573442b09@github.com>
Message-ID: <Lqj_xG1oSM9VysqB8S3EyWvvjCO1svYcp-_wSox0lE4=.528482ec-7362-4e4e-a67d-ddd2891103e2@github.com>

On Wed, 16 Jul 2025 21:25:05 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> IIUC `retire` a region means that the region has been retired from allocation, however, the particular region is in active use just that we can no longer allocate out of this region. Eventually, this region will be evacuated and `hr_clear()` called. So `record_activity()` during retirement is redundant.
>
> `hr_clear` is called when the region is freed in `G1CollectedHeap::free_region`

You're right about removing the redundant calls. Plus, my logic already ensures only empty regions are considered for uncommitting, so retired region timestamps wouldn't affect decisions anyway

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211954818

From mbeckwit at openjdk.org  Thu Jul 17 01:43:48 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 17 Jul 2025 01:43:48 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <afYpHnOffnW2fT4FmjHeElzjWnHQrS_OONa7qak-VjI=.555b08c8-40c3-4029-b03b-736ff3ccfcbf@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
 <6tGL2PHITH0ok_qunRGR_EojSnJuPLX5ZLaw7ZeJeRU=.95af9d2a-7e2e-45b0-b72d-ede91adaadc4@github.com>
 <afYpHnOffnW2fT4FmjHeElzjWnHQrS_OONa7qak-VjI=.555b08c8-40c3-4029-b03b-736ff3ccfcbf@github.com>
Message-ID: <gSy52386qtGETIX2xeOoxWFBoH0qy-ENIQPh62jd5cA=.369a4c53-2906-42c6-b186-b51cf205403b@github.com>

On Wed, 16 Jul 2025 21:09:46 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>>> For existing Heap Resizing tasks, we use the tags `(gc, ergo, heap)`, I would suggest we maintain that.
>> 
>> I'd like to discuss the logging tag choice. While I understand the consistency argument for using (gc,ergo,heap), I believe (gc,sizing) is more appropriate here because:
>> 
>> 1. This is a distinct sizing mechanism, not traditional ergonomic heap management
>> 2. Users troubleshooting time-based sizing specifically will benefit from a dedicated tag
>> 3. It aligns with the feature name and purpose
>> 4. It provides better separation of concerns for logging
>> 
>> Would you be open to keeping (gc,sizing) for semantic clarity?
>
> My argument is related to consistency, if there are reasons to have this logging distinct from the `(gc, ergo, heap)`, that is fine by me.

Thank you for being open to the distinct logging tags. I'll keep (gc,sizing) to maintain the semantic clarity for time-based heap sizing troubleshooting. This will help users and support teams isolate time-based sizing behavior from traditional ergonomic heap management.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2211958648

From mbeckwit at openjdk.org  Thu Jul 17 01:50:59 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 17 Jul 2025 01:50:59 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
Message-ID: <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

  8357445: Remove redundant record_activity calls and leftover initialize call
  
  - Remove record_activity() from retirement methods as hr_clear() is always last
  - Remove leftover initialize() call since initialization moved to constructor
  - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26240/files
  - new: https://git.openjdk.org/jdk/pull/26240/files/8897a2b0..23a732e6

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

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

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

From tschatzl at openjdk.org  Thu Jul 17 07:14:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Jul 2025 07:14:57 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
Message-ID: <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com>

On Thu, 17 Jul 2025 01:50:59 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
>> 
>> Implement time-based heap uncommit for G1 during idle periods.
>> 
>> Key changes:
>> - Added G1HeapEvaluationTask for periodic heap evaluation
>> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
>> - Implemented time-based heap sizing policy with configurable uncommit delay
>> - Added region activity tracking with last access timestamps
>> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
>> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
>> - Added 'sizing' log tag for heap sizing operations
>> 
>> Comprehensive Test Coverage:
>> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
>> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
>> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
>> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
>> 
>> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357445: Remove redundant record_activity calls and leftover initialize call
>   
>   - Remove record_activity() from retirement methods as hr_clear() is always last
>   - Remove leftover initialize() call since initialization moved to constructor
>   - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap

Some initial drive-by comments...

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1136:

> 1134:   if (SafepointSynchronize::is_at_safepoint()) {
> 1135:     shrink(shrink_bytes);
> 1136:     return true;                     // we *did* something

(Full) Sentence length comments should follow sentence style: Initial capitalization and full stop at the end. Not sure if the emphasis should be kept, seems to be overused (and I do not think we use it a lot in G1 code).
(Please no markdown btw :) )

src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 64:

> 62:     // Time-based evaluation only handles uncommit/shrinking, never expansion
> 63:     if (should_expand) {
> 64:       log_warning(gc, sizing)("Time-based evaluation unexpected expansion request ignored (resize_amount=%zuB)", resize_amount);

I think "Time-based evaluation" as a kind of extra tag seems to be too unspecific: Time based evaluation of what?

I.e. the heap sizing based on GCTimeRatio is also "time-based". Also the messages partially seem to be inconsistent at first glance: Somebody this "time-based" prefix is there, sometimes not. Also sometimes it reads "Time-based evaluation", sometimes "Time-based heap sizing", sometimes having ":" in them, sometimes not.

If we add an extra tag, that "Time-based*" prefix might be superfluous, particularly if we keep the `sizing`for this kind of stuff (or even make it more specific).

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

> 542:     size_t max_shrink_bytes = current_heap > min_heap ? current_heap - min_heap : 0;
> 543: 
> 544:     log_trace(gc, sizing)("Time-based evaluation details: current_heap=%zuB min_heap=%zuB "

I do not think `trace`log messages need the "details" in `Time-based evaluation details" - this is already indicated by the log level.

Also, in contrast to other "Time-based evaluation" messages this has a ":" at the end, which is inconsistent.

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

> 72: //
> 73: class G1HeapSizingPolicy: public CHeapObj<mtGC> {
> 74:   static jlong _uncommit_delay_ms;  // Delay before uncommitting inactive regions

It's generally better to use `Ticks`/`Timespan` etc for times as they a) have higher precision and b) one does not need to carry the unit in them. Just convert when you need. They are also distinct types so that wrong assignment can not happen (like a value containing seconds to something that ought to contain milliseconds).
One can only round down etc. when needed.

Also, `jlong` should be avoided, as it is originally a "J"ava type, i.e. for Java interfacing (yeah, it has crept in over time for various reasons).

src/hotspot/share/gc/g1/g1_globals.hpp line 391:

> 389:           "attempt to uncommit memory")                                     \
> 390:           range(1, max_uintx)                                               \
> 391:                                                                             \

Just an initial drive-by comment:
* not sure I would make `G1UseTimeBasedHeapSizing` experimental (_maybe_ G1MinRegionsToUncommit`, but it seems very similar in use), and disabled by default. I would enable it by default, and make it diagnostic. While the difference between experimental and diagnostic is somewhat arguable, the former is more for developers to enable/disable, and the latter for support team to handle support issues (i.e. diagnose them).
As for the default value, I expect this to be beneficial always, and the default value indicates a long enough default delay for doing that, i.e. the overhead should be negligible.
* new manageble flags need a CSR to officially announce the functionality (and the feature needs a release note). Probably also tuning guide changes, but since it is not editable by the public, we at Oracle will handle this.
I am not yet completely convinced to make these manageable, although I can imagine some reasons. Can you give a good use case you specifically encountered to do so?

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

PR Review: https://git.openjdk.org/jdk/pull/26240#pullrequestreview-3028172712
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2212461687
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2212467046
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2212478262
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2212469596
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2212456893

From tschatzl at openjdk.org  Thu Jul 17 07:14:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Jul 2025 07:14:58 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <gSy52386qtGETIX2xeOoxWFBoH0qy-ENIQPh62jd5cA=.369a4c53-2906-42c6-b186-b51cf205403b@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
 <6tGL2PHITH0ok_qunRGR_EojSnJuPLX5ZLaw7ZeJeRU=.95af9d2a-7e2e-45b0-b72d-ede91adaadc4@github.com>
 <afYpHnOffnW2fT4FmjHeElzjWnHQrS_OONa7qak-VjI=.555b08c8-40c3-4029-b03b-736ff3ccfcbf@github.com>
 <gSy52386qtGETIX2xeOoxWFBoH0qy-ENIQPh62jd5cA=.369a4c53-2906-42c6-b186-b51cf205403b@github.com>
Message-ID: <ec4J7klHi7SdNK2Dym6XjoSjZXdHa1Ukx59P-2p-RwM=.7168041e-b7d6-4e28-8a29-da95896e657c@github.com>

On Thu, 17 Jul 2025 01:41:35 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> My argument is related to consistency, if there are reasons to have this logging distinct from the `(gc, ergo, heap)`, that is fine by me.
>
> Thank you for being open to the distinct logging tags. I'll keep (gc,sizing) to maintain the semantic clarity for time-based heap sizing troubleshooting. This will help users and support teams isolate time-based sizing behavior from traditional ergonomic heap management.

Probably I would prefer `gc, ergo, sizing` - heap sizing is part of ergonomics and doing so allows you to specifically enable it and the same time (with `gc+ergo*`) catch it with other ergonomic decisions.

Potentially more log messages should be moved to that logging too. Maybe make a CR that says something like "G1: Consider putting heap sizing decisions under gc+ergo+sizing`.

Note that I think we somewhat already use `gc+ergo+heap` for that, so the new flag might be redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2212456529

From tschatzl at openjdk.org  Thu Jul 17 07:20:55 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Jul 2025 07:20:55 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
 <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com>
Message-ID: <BycMAws6MDgTjdcuOnelo3nS41ctUnT1ulfM1UepbZk=.b94e7398-74b7-46a7-a1d1-5e59ed075a76@github.com>

On Thu, 17 Jul 2025 06:58:15 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357445: Remove redundant record_activity calls and leftover initialize call
>>   
>>   - Remove record_activity() from retirement methods as hr_clear() is always last
>>   - Remove leftover initialize() call since initialization moved to constructor
>>   - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap
>
> src/hotspot/share/gc/g1/g1_globals.hpp line 391:
> 
>> 389:           "attempt to uncommit memory")                                     \
>> 390:           range(1, max_uintx)                                               \
>> 391:                                                                             \
> 
> Just an initial drive-by comment:
> * not sure I would make `G1UseTimeBasedHeapSizing` experimental (_maybe_ G1MinRegionsToUncommit`, but it seems very similar in use), and disabled by default. I would enable it by default, and make it diagnostic. While the difference between experimental and diagnostic is somewhat arguable, the former is more for developers to enable/disable, and the latter for support team to handle support issues (i.e. diagnose them).
> As for the default value, I expect this to be beneficial always, and the default value indicates a long enough default delay for doing that, i.e. the overhead should be negligible.
> * new manageble flags need a CSR to officially announce the functionality (and the feature needs a release note). Probably also tuning guide changes, but since it is not editable by the public, we at Oracle will handle this.
> I am not yet completely convinced to make these manageable, although I can imagine some reasons. Can you give a good use case you specifically encountered to do so?

Release-note howto: https://openjdk.org/guide/index.html#release-notes. For now I tagged the issue with `release-note=yes`. Note that it can be written later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2212494378

From tschatzl at openjdk.org  Thu Jul 17 07:35:51 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Jul 2025 07:35:51 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <BycMAws6MDgTjdcuOnelo3nS41ctUnT1ulfM1UepbZk=.b94e7398-74b7-46a7-a1d1-5e59ed075a76@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
 <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com>
 <BycMAws6MDgTjdcuOnelo3nS41ctUnT1ulfM1UepbZk=.b94e7398-74b7-46a7-a1d1-5e59ed075a76@github.com>
Message-ID: <y84Sr_Pvl3CTKlVngL3zNqG-dujfk5dxgDOjcZJ_lC4=.737cc414-7375-4904-a7f0-6b51eae6281b@github.com>

On Thu, 17 Jul 2025 07:17:49 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1_globals.hpp line 391:
>> 
>>> 389:           "attempt to uncommit memory")                                     \
>>> 390:           range(1, max_uintx)                                               \
>>> 391:                                                                             \
>> 
>> Just an initial drive-by comment:
>> * not sure I would make `G1UseTimeBasedHeapSizing` experimental (_maybe_ G1MinRegionsToUncommit`, but it seems very similar in use), and disabled by default. I would enable it by default, and make it diagnostic. While the difference between experimental and diagnostic is somewhat arguable, the former is more for developers to enable/disable, and the latter for support team to handle support issues (i.e. diagnose them).
>> As for the default value, I expect this to be beneficial always, and the default value indicates a long enough default delay for doing that, i.e. the overhead should be negligible.
>> * new manageble flags need a CSR to officially announce the functionality (and the feature needs a release note). Probably also tuning guide changes, but since it is not editable by the public, we at Oracle will handle this.
>> I am not yet completely convinced to make these manageable, although I can imagine some reasons. Can you give a good use case you specifically encountered to do so?
>
> Release-note howto: https://openjdk.org/guide/index.html#release-notes. For now I tagged the issue with `release-note=yes`. Note that it can be written later.

One reason why I do not see the need for these flags to be manageable is that this heap shrinking is a supportive function if the application is "idle". Main heap sizing should be done by the existing heap sizing/AHS at GC events.

>From the CR text:
>  Doing heap sizing based on garbage collections has a big disadvantage: if there are no garbage collections (due to no application activity) there is a risk that a large amount of heap is kept committed unnecessarily *for a long time*. 
(emphasis mine)

If we are talking about "a long time", so there does not seem to be a need for changing it during runtime (or change it at all). It should not matter if that "long time" is "long time +- small epsilon", and so, allowing dynamic change of "a long time" to another "long time" seems unnecessary without a very good use case.

Please consider not necessarily the current situation, but with "full" AHS.

Another question is whether you had thoughts about the interaction with (JDK-8213198)[https://bugs.openjdk.org/browse/JDK-8213198], as this change seems to be a subset of the other. (That's just curiosity from me, I think this feature is useful as is, and if the other ever materializes, we can always reconsider).

Otoh decreasing the heap by this mechanism will eventually trigger a marking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2212529861

From ayang at openjdk.org  Thu Jul 17 10:08:48 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 17 Jul 2025 10:08:48 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
In-Reply-To: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
Message-ID: <K48H6KBuQwG7kDdgjeY36LzFozkwyxrfyd0YRZt6Q2I=.3e68e23e-9b1c-4da3-abbd-e4603eb2e2f2@github.com>

On Wed, 16 Jul 2025 13:55:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi,
> 
> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included.
> 
> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing.  Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios.
> 
> Testing: Tier 1

src/hotspot/share/gc/g1/g1Analytics.cpp line 174:

> 172:   // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
> 173:   uint num_cpus = (uint)os::active_processor_count();
> 174:   num_cpus = MIN2(num_cpus, MAX2(ConcGCThreads, ParallelGCThreads));

Why the use of `ParallelGCThreads`? I thought parallel-threads are used only for stw-work but the current context about concurrent-work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2212920774

From iwalulya at openjdk.org  Thu Jul 17 11:43:50 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Jul 2025 11:43:50 GMT
Subject: RFR: 8361404: Parallel: Group all class unloading logc at the end
 of marking phase
In-Reply-To: <ITJqw3PGoTpqZFWa0_u-Moyk4inPAl1HG-892AYS_5M=.648c95b0-829e-424e-b7ba-77224c739a80@github.com>
References: <ITJqw3PGoTpqZFWa0_u-Moyk4inPAl1HG-892AYS_5M=.648c95b0-829e-424e-b7ba-77224c739a80@github.com>
Message-ID: <RxxvtoGFuFHMHaKDXXsrhrSSomzPo6QamHXeAvzuLbg=.61eb6b14-54b9-4f3e-a5c1-bafa2fe865b7@github.com>

On Fri, 4 Jul 2025 11:15:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 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

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26130#pullrequestreview-3029161803

From iwalulya at openjdk.org  Thu Jul 17 11:43:50 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Jul 2025 11:43:50 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: <DzdkP8l8MzS-TrWE5XlbkwUqFE30sSFGYQ3ZYZkmQ4s=.d1c85a72-e8c8-4fbd-88d3-f055486ca3eb@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

Marked as reviewed by iwalulya (Reviewer).

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

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

From ayang at openjdk.org  Thu Jul 17 12:14:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 17 Jul 2025 12:14:55 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: <-xCjyEj4DEuXwHzTzktUzr5KUdJCP01tBFhc_XrZK_c=.e2d5d108-4451-4127-9478-34f44f96fc3b@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

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26089#issuecomment-3083827476

From ayang at openjdk.org  Thu Jul 17 12:14:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 17 Jul 2025 12:14:55 GMT
Subject: Integrated: 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: <XhhKYzLY5iFblrR1ioJk341-kKeBVRXWYuDU12qJXjY=.df7f4c07-2466-4911-9f59-7bda92e4dc4e@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

This pull request has now been integrated.

Changeset: bc9ece96
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc9ece9698cf13c9df3b2282bfcae2458a767713
Stats:     3 lines in 1 file changed: 1 ins; 1 del; 1 mod

8361204: Parallel: Skip visiting per-thread nmethods during young GC

Reviewed-by: tschatzl, iwalulya

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

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

From iwalulya at openjdk.org  Thu Jul 17 12:25:55 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Jul 2025 12:25:55 GMT
Subject: RFR: 8362278: G1: Consolidate functions for recording pause start
 time [v3]
In-Reply-To: <FLm9XpjTu1JrMiSWgKwMgdAsEU-2QVg5O3cgSYrz4EU=.47a93304-2d58-4e7a-9d06-b84f55a9306b@github.com>
References: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
 <FLm9XpjTu1JrMiSWgKwMgdAsEU-2QVg5O3cgSYrz4EU=.47a93304-2d58-4e7a-9d06-b84f55a9306b@github.com>
Message-ID: <QTdj-M1N0b3gdNkzDzv2H4e5GBCZ-CsjeBznV61z_go=.f05cffd6-f2d9-40c1-a6de-38f767e2b6dc@github.com>

On Wed, 16 Jul 2025 11:24:04 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this refactoring change to unify the recording of GC Pause start-time.
>> 
>> Testing: Tier 1
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas suggestion

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26323#issuecomment-3083862610

From iwalulya at openjdk.org  Thu Jul 17 12:25:56 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Jul 2025 12:25:56 GMT
Subject: Integrated: 8362278: G1: Consolidate functions for recording pause
 start time
In-Reply-To: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
References: <0dFuj_tOFMMBj62mxsAviIDGqR7yWDvn9Jv_YTT86C0=.d257f6a9-db28-4194-a4a4-5330938382ef@github.com>
Message-ID: <lZGShzApIzbC3a7zHPxx1JSRWTCXoutrEQ9VRlx1gIs=.768d226f-6b44-4365-82c1-220ee962a9c5@github.com>

On Tue, 15 Jul 2025 16:13:34 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi,
> 
> Please review this refactoring change to unify the recording of GC Pause start-time.
> 
> Testing: Tier 1

This pull request has now been integrated.

Changeset: cb9358b5
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb9358b5618c0c222f02bc77c9a6e42d30564f34
Stats:     58 lines in 6 files changed: 13 ins; 30 del; 15 mod

8362278: G1: Consolidate functions for recording pause start time

Reviewed-by: tschatzl, ayang

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

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

From iwalulya at openjdk.org  Thu Jul 17 12:33:27 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Jul 2025 12:33:27 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v2]
In-Reply-To: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
Message-ID: <VXzTeeUIZLEiHNk5ulVqYc57RHzBB3BvjJ84ahvxSU4=.99c45e6c-87e1-4160-a8b2-5e9ff44febe0@github.com>

> Hi,
> 
> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included.
> 
> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing.  Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios.
> 
> Testing: Tier 1

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

 - Merge branch 'NormalizeTiming' into ConcCPUImpact
 - Thomas suggestion
 - Thomas Review
 - reorder
 - concurrent gc impact
 - clean out
 - init

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

Changes: https://git.openjdk.org/jdk/pull/26351/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26351&range=01
  Stats: 97 lines in 8 files changed: 50 ins; 30 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/26351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26351/head:pull/26351

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

From iwalulya at openjdk.org  Thu Jul 17 12:38:58 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Jul 2025 12:38:58 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v2]
In-Reply-To: <K48H6KBuQwG7kDdgjeY36LzFozkwyxrfyd0YRZt6Q2I=.3e68e23e-9b1c-4da3-abbd-e4603eb2e2f2@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <K48H6KBuQwG7kDdgjeY36LzFozkwyxrfyd0YRZt6Q2I=.3e68e23e-9b1c-4da3-abbd-e4603eb2e2f2@github.com>
Message-ID: <my5rl32VDZwyyMr5clKQB9LSJi7DzwB7Kzsy1Du_XgA=.183e915a-1a89-49e5-86eb-255153990083@github.com>

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

>> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge branch 'NormalizeTiming' into ConcCPUImpact
>>  - Thomas suggestion
>>  - Thomas Review
>>  - reorder
>>  - concurrent gc impact
>>  - clean out
>>  - init
>
> src/hotspot/share/gc/g1/g1Analytics.cpp line 174:
> 
>> 172:   // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
>> 173:   uint num_cpus = (uint)os::active_processor_count();
>> 174:   num_cpus = MIN2(num_cpus, MAX2(ConcGCThreads, ParallelGCThreads));
> 
> Why the use of `ParallelGCThreads`? I thought parallel-threads are used only for stw-work but the current context about concurrent-work.

`G1ConcRefinementThreads` and `ConcGCThreads` are by default bounded by  ParallelGCThreads, but maybe we can use `G1ConcRefinementThreads` directly here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2213222502

From iwalulya at openjdk.org  Thu Jul 17 12:40:00 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Jul 2025 12:40:00 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
Message-ID: <sKysUUUhzjgodDBw0yEihSvzZ0aiLWrAaWcO2C8x-sM=.b8efdfc8-b008-43a9-9b6b-291855e1ef11@github.com>

On Thu, 17 Jul 2025 01:50:59 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
>> 
>> Implement time-based heap uncommit for G1 during idle periods.
>> 
>> Key changes:
>> - Added G1HeapEvaluationTask for periodic heap evaluation
>> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
>> - Implemented time-based heap sizing policy with configurable uncommit delay
>> - Added region activity tracking with last access timestamps
>> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
>> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
>> - Added 'sizing' log tag for heap sizing operations
>> 
>> Comprehensive Test Coverage:
>> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
>> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
>> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
>> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
>> 
>> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357445: Remove redundant record_activity calls and leftover initialize call
>   
>   - Remove record_activity() from retirement methods as hr_clear() is always last
>   - Remove leftover initialize() call since initialization moved to constructor
>   - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap

src/hotspot/share/gc/g1/g1HeapEvaluationTask.hpp line 36:

> 34: // Time-based heap evaluation task that runs during idle periods.
> 35: // Uses PeriodicTask rather than G1ServiceTask due to build compatibility issues
> 36: // in JDK 25+. PeriodicTask's 10ms granularity is adequate for heap evaluation

Can you please elaborate on these "compatibility issues"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2213223680

From iwalulya at openjdk.org  Thu Jul 17 13:16:29 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Jul 2025 13:16:29 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
Message-ID: <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>

> Hi,
> 
> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included.
> 
> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing.  Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios.
> 
> Testing: Tier 1

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

 - cleanup after merge
 - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact
 - Merge branch 'NormalizeTiming' into ConcCPUImpact
 - Thomas suggestion
 - Thomas Review
 - reorder
 - concurrent gc impact
 - clean out
 - init

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

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

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

From ayang at openjdk.org  Thu Jul 17 13:59:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 17 Jul 2025 13:59:58 GMT
Subject: RFR: 8361404: Parallel: Group all class unloading logc at the end
 of marking phase
In-Reply-To: <ITJqw3PGoTpqZFWa0_u-Moyk4inPAl1HG-892AYS_5M=.648c95b0-829e-424e-b7ba-77224c739a80@github.com>
References: <ITJqw3PGoTpqZFWa0_u-Moyk4inPAl1HG-892AYS_5M=.648c95b0-829e-424e-b7ba-77224c739a80@github.com>
Message-ID: <OWnb1bxe0OC2g2otcEWjOx8tDKqMhHWGTRmh4UuTmSY=.209e64cf-75b1-4387-847a-76d5d9ea2e2d@github.com>

On Fri, 4 Jul 2025 11:15:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 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

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26130#issuecomment-3084175519

From ayang at openjdk.org  Thu Jul 17 13:59:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 17 Jul 2025 13:59:58 GMT
Subject: Integrated: 8361404: Parallel: Group all class unloading logc at the
 end of marking phase
In-Reply-To: <ITJqw3PGoTpqZFWa0_u-Moyk4inPAl1HG-892AYS_5M=.648c95b0-829e-424e-b7ba-77224c739a80@github.com>
References: <ITJqw3PGoTpqZFWa0_u-Moyk4inPAl1HG-892AYS_5M=.648c95b0-829e-424e-b7ba-77224c739a80@github.com>
Message-ID: <L4D_87kjNQA3OZXLO7y-jpm4dqZC0j7IURMn0bzAqZ8=.5cbf3515-473f-45ca-b6bd-e5212d330b18@github.com>

On Fri, 4 Jul 2025 11:15:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: 5ed72775
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ed72775a775d6c96be6de7d9540dc0a80cdd67b
Stats:     28 lines in 1 file changed: 11 ins; 14 del; 3 mod

8361404: Parallel: Group all class unloading logc at the end of marking phase

Reviewed-by: tschatzl, iwalulya

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

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

From tschatzl at openjdk.org  Thu Jul 17 14:50:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Jul 2025 14:50:46 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v43]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <TtV0oPZQZrjta5-y-4_GqT7Xk0Qpxt2BlASdcJYFrP4=.78b09f04-0cd9-453d-8ca1-23805bca7982@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 59 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - 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)
 - ... and 49 more: https://git.openjdk.org/jdk/compare/ea774b74...4b21868a

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=42
  Stats: 7120 lines in 112 files changed: 2589 ins; 3590 del; 941 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 kbarrett at openjdk.org  Thu Jul 17 14:52:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 17 Jul 2025 14:52:51 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v3]
In-Reply-To: <7B9Nf7B04cW2IUoftnexGjyNjvf_gIOG5YiVXlAQlGc=.d50a0051-fe7d-43e7-9c07-9618ae89e1d5@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <7B9Nf7B04cW2IUoftnexGjyNjvf_gIOG5YiVXlAQlGc=.d50a0051-fe7d-43e7-9c07-9618ae89e1d5@github.com>
Message-ID: <dpTYY_ZeLbw9sYN0GYgxqrgQBJKj-nIwRKLZ9Oe0BvU=.f08810f5-9a6a-41ec-8093-e6de4e463583@github.com>

On Wed, 16 Jul 2025 08:28:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - * more refactoring, comments
>  - * kbarrett review part 2 (slightly incomplete)
>  - * kbarrett review - 1
>  - * initial kbarrett refactoring

A few minor nits, but generally looks good.

I don't have any (possibly) better name suggestions for the new helper functions
used by `try_collect_concurrently`.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1733:

> 1731:     // If VMOp failed because a cycle was already in progress, it
> 1732:     // is now complete.  But it didn't finish this user-requested
> 1733:     // GC, so try again.

This assumes this is called after calling wait_full_mark_finished for the same op.  Might be
saying that.  Perhaps that should be a comment about the function as a whole.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1846:

> 1844:         continue;
> 1845:       }
> 1846:      } else if (!GCCause::is_user_requested_gc(cause)) {

I think this line is indented one space too many.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1848:

> 1846:      } else if (!GCCause::is_user_requested_gc(cause)) {
> 1847:       // For an "automatic" (not user-requested) collection, we just need to
> 1848:       // ensure that progress is made.

Maybe assert that the cause is one of the ones we expect here, rather than just defaulting to the
non-user-requested residue? That way, if a new cause gets added one is forced to look here with
an eye toward what should be done for the new cause.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 284:

> 282:                                uint old_marking_started_after,
> 283:                                uint old_marking_completed_after);
> 284:   // Attempt to start a concurrent cycle with the indicated cause.

Add a blank line separating the new decl from the follower.

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

PR Review: https://git.openjdk.org/jdk/pull/26189#pullrequestreview-3029849241
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2213549513
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2213553325
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2213559175
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2213567475

From iwalulya at openjdk.org  Thu Jul 17 15:16:49 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Jul 2025 15:16:49 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
Message-ID: <EqQ-Fr4-JeG1L7_s4wtzmIFkCn0uhJPIM0Ii7ViD-RQ=.56286259-e412-4b23-9569-0c48ddf52ad2@github.com>

On Thu, 17 Jul 2025 01:50:59 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
>> 
>> Implement time-based heap uncommit for G1 during idle periods.
>> 
>> Key changes:
>> - Added G1HeapEvaluationTask for periodic heap evaluation
>> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
>> - Implemented time-based heap sizing policy with configurable uncommit delay
>> - Added region activity tracking with last access timestamps
>> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
>> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
>> - Added 'sizing' log tag for heap sizing operations
>> 
>> Comprehensive Test Coverage:
>> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
>> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
>> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
>> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
>> 
>> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357445: Remove redundant record_activity calls and leftover initialize call
>   
>   - Remove record_activity() from retirement methods as hr_clear() is always last
>   - Remove leftover initialize() call since initialization moved to constructor
>   - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap

Hi,

There appears to be a disconnect between the `get_uncommit_candidates` logic and the actual heap shrinking performed by `G1CollectedHeap::shrink`. While `G1HeapSizingPolicy::evaluate_heap_resize` determines the number of bytes to shrink (via shrink_bytes) and passes this to the heap shrink logic, the regions identified as uncommit candidates are not explicitly communicated or prioritized during the shrink operation.

As a result, the heap may be shrunk without necessarily uncommitting the specific regions previously marked as uncommit candidates. This can lead to a scenario where those regions remain committed even after the shrink, potentially triggering repeated shrink attempts in subsequent calls to `G1HeapSizingPolicy::evaluate_heap_resize`.

Is this understanding correct?

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

PR Comment: https://git.openjdk.org/jdk/pull/26240#issuecomment-3084463449

From wkemper at openjdk.org  Thu Jul 17 16:52:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 17 Jul 2025 16:52:55 GMT
Subject: [jdk25] Integrated: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated
In-Reply-To: <iJ7vJLthvf5aeNb-b9hwFib-WOl81gB7quOBmLKa_xQ=.f6031290-3a25-4343-beb4-69fe68fc64d6@github.com>
References: <iJ7vJLthvf5aeNb-b9hwFib-WOl81gB7quOBmLKa_xQ=.f6031290-3a25-4343-beb4-69fe68fc64d6@github.com>
Message-ID: <64wSxikjR615hnoXAC6g6VUJb3GLD7G-uOjuOK7dzSY=.3933600f-1307-48bf-904e-97e22b00d3b6@github.com>

On Wed, 16 Jul 2025 18:04:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes a crash in Shenandoah (ILW = P3). Only touches Shenandoah code.

This pull request has now been integrated.

Changeset: 347084bf
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/347084bfbdbf048cd50c0e13e43ae53f6da77e6e
Stats:     20 lines in 2 files changed: 3 ins; 7 del; 10 mod

8360288: Shenandoah crash at size_given_klass in op_degenerated

Reviewed-by: shade
Backport-of: 3b44d7bfa4d78e3ec715fce1863e052852f33180

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

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

From duke at openjdk.org  Thu Jul 17 23:27:58 2025
From: duke at openjdk.org (duke)
Date: Thu, 17 Jul 2025 23:27:58 GMT
Subject: Withdrawn: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <0OTljarJSR8e3RF0idSM_uyrmHWbKx-58H1OUV6Ezzc=.f2920aa6-bfcc-4394-a4c8-a0d08d9b5dc0@github.com>

On Mon, 31 Mar 2025 03:17:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

This pull request has been closed without being integrated.

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

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

From ysr at openjdk.org  Fri Jul 18 00:54:19 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 18 Jul 2025 00:54:19 GMT
Subject: RFR: 8350050: Shenandoah: Disable and purge allocation pacing
 support [v2]
In-Reply-To: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
Message-ID: <djw4zXuHgI9245b08giMWPOHrqJmuzlYd7CJxkRCIEk=.8548da0c-2c40-44a7-a120-862f44f1dd63@github.com>

> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, have been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational She
 nandoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
> 
> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
> 
> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
> 
> 
> ### SpecJBB
> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
> 
>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
> --------------------------|--------------------|----------------------------------|
> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
> -ShenandoahPacing          |              24.8            |                               *26.9*                |
> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
> 
> ### Testing:
> - SPECjbb
> - Code Pipeline Stress
> - Perf Dashboard
> -----...

Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:

  Remove some dangling references and unused variables identified in the
  code review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24002/files
  - new: https://git.openjdk.org/jdk/pull/24002/files/645bb879..589bde35

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

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

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

From ysr at openjdk.org  Fri Jul 18 00:54:19 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 18 Jul 2025 00:54:19 GMT
Subject: RFR: 8350050: Shenandoah: Disable and purge allocation pacing
 support [v2]
In-Reply-To: <afoU7QJP-J6IGDKVZ7YE5797davpJFXxNf0x3wgSWec=.d64c9fa0-cbc0-401b-82e2-a408d75aa3c0@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
 <afoU7QJP-J6IGDKVZ7YE5797davpJFXxNf0x3wgSWec=.d64c9fa0-cbc0-401b-82e2-a408d75aa3c0@github.com>
Message-ID: <eQ-MGB323Ch5sNe3RNqD3SXgN5x93xiqp7ipPEa4bWg=.f1e3822d-5505-459c-9b55-5d8e76cc07e2@github.com>

On Mon, 14 Jul 2025 22:27:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove some dangling references and unused variables identified in the
>>   code review.
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 839:
> 
>> 837: 
>> 838:             _heap->marked_object_oop_iterate(r, &cl, update_watermark);
>> 839:             region_progress = true;
> 
> I don't think we need this `region_progress` variable anymore.

Good catch... Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24002#discussion_r2214603567

From tschatzl at openjdk.org  Fri Jul 18 11:51:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 18 Jul 2025 11:51:35 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v4]
In-Reply-To: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
Message-ID: <sbO5a6uPe6d2fjv0VmS2lEKJ8kKhDAdPVPGAf5amDUY=.10436ad6-3539-4a51-8f4f-7c972370d63f@github.com>

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

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

 - Merge branch 'master' into 8350621-code-cache-mgmt-hang
 - * kbarrett-review
 - Merge branch 'master' into 8350621-code-cache-mgmt-hang
 - * more refactoring, comments
 - * kbarrett review part 2 (slightly incomplete)
 - * kbarrett review - 1
 - * initial kbarrett refactoring
 - * kbarret review:
     - restructure code in `try_collect_concurrently`
     - fix asserts - they only worked in the test because of whitebox being active
     - fix comments
   * threalmdoerr review:
     - fix test to be more lenient
 - * some whitespace fixes
 - 8350621
   
   Hi all,
   
     please review this change to avoid CodeCache triggered GCs temporarily being ignored.
   
   In particular, G1 does not make sure when its `collect()` method is called during a
   concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs
   after that request. This makes it so that some internal flag is not reset appropriately,
   stuck until the next code unloading (caused by e.g. a regular concurrent cycle being
   triggered).
   
   Testing: tier1-5
   
   Thanks,
     Thomas

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

Changes: https://git.openjdk.org/jdk/pull/26189/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26189&range=03
  Stats: 392 lines in 8 files changed: 340 ins; 43 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26189/head:pull/26189

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

From tschatzl at openjdk.org  Fri Jul 18 12:31:50 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 18 Jul 2025 12:31:50 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v4]
In-Reply-To: <b2IAtjznnLPiZYVGmbN75PZknMKBTmbyHUUA-mfpuj4=.b09d2ed7-add0-40a8-b345-c2bd0df82f72@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <b2IAtjznnLPiZYVGmbN75PZknMKBTmbyHUUA-mfpuj4=.b09d2ed7-add0-40a8-b345-c2bd0df82f72@github.com>
Message-ID: <5Xpq7TTxw0gAJpIaNwzDE2Vx6U8Qb3grQ1jUUy1jDhc=.9d8aa441-c92e-46b7-9028-49e05c26c4d8@github.com>

On Tue, 15 Jul 2025 08:29:23 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 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:
> 
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - sgc-roots

I played around with the two options, either cleaning up the existing code and keep the `process_roots`, and a self-written variant of this:
https://github.com/openjdk/jdk/commit/e4355dc689afa56f214588630a15d911737422a9 (cleanup)
https://github.com/openjdk/jdk/commit/9a0a4ff27d8ae6fdea59592db3571e9e5cdbccd7 (same suggestion as here)

(untested :) )

So I think while I still somewhat prefer the old style (everything in one place), there is reason to treat these differently, and so the second variant does make some sense.
Particularly with the optimization/changes this change introduced, there really is little common code.

What the second variant still does not help with is easy comparison of the three variants; I only found that probably when not class unloading, it is probably not necessary to go through the thread's nmethods (https://bugs.openjdk.org/browse/JDK-8362588) in the full gc mark phase. All(?) embedded oops should be reachable by `InstanceKlass::_methods` of all CLDs (or, if that is not sufficient, why isn't it required to, similar to G1/the adjust pointer phase to walk through the entire codecache)....

Maybe the just added comments could be improved more, see the examples in the above change to spell out exactly _why_ particular parameters are chosen.

I particularly do not like this one:
>    // Only nmethods that contain pointers into-young need to be processed
    // during young-gc, and they are tracked in ScavengableNMethods
    Threads::oops_do(&oop_cl, &nmethod_cl);
    ScavengableNMethods::nmethods_do(&nmethod_cl);

So the comment begs the question why the `nmethod_cl` is passed to `Threads::oops_do` if "they are tracked by `ScavengableNMethod`" - as has already been pointed out, this is unnecessary, but it is a bit awkward to me that the documentation in this change points out an issue :) 

Also in the current change the code uses both `_cl` and `_closure` postfixes for the closures. Would be nice to use one.

Still undecided whether this change is an improvement, but not too concerned about it any more. If there is a set of additional roots common to all of them in the future, that one and the `OopStorageSet` one can be factored out.

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

PR Comment: https://git.openjdk.org/jdk/pull/26038#issuecomment-3089331707

From ayang at openjdk.org  Fri Jul 18 13:13:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 18 Jul 2025 13:13:38 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@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 33 commits:

 - merge
 - Merge branch 'master' into pgc-size-policy
 - review
 - 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
 - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=21
  Stats: 4362 lines in 31 files changed: 507 ins; 3470 del; 385 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  Fri Jul 18 13:14:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 18 Jul 2025 13:14:38 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v5]
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: <VnLSTr5JZTBzn1pkKeL1PP_8w6KS5aHeJEuXBbkmUBw=.2fb54f30-57ae-47be-adfb-2bf863219996@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 eight additional commits since the last revision:

 - review
 - Merge branch 'master' into sgc-roots
 - review
 - Merge branch 'master' into sgc-roots
 - 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/59432994..ab4088c0

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

  Stats: 12525 lines in 375 files changed: 9753 ins; 972 del; 1800 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 18 13:14:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 18 Jul 2025 13:14:41 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v4]
In-Reply-To: <b2IAtjznnLPiZYVGmbN75PZknMKBTmbyHUUA-mfpuj4=.b09d2ed7-add0-40a8-b345-c2bd0df82f72@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <b2IAtjznnLPiZYVGmbN75PZknMKBTmbyHUUA-mfpuj4=.b09d2ed7-add0-40a8-b345-c2bd0df82f72@github.com>
Message-ID: <SherE8VngSHj1IM4JRv6UokqqxIEH5cWrkNL_gvsVgg=.4491ae68-6575-4560-8ce3-5f3a305d6a77@github.com>

On Tue, 15 Jul 2025 08:29:23 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 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:
> 
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - sgc-roots

Updated comments. I kept the numbering as I find it helpful to capture what roots are dealt with in each context.

> I particularly do not like this one:...

Revised. I was planning to fix that in a followup PR, as it's beyond "inlining".

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

PR Comment: https://git.openjdk.org/jdk/pull/26038#issuecomment-3089442129

From mbeckwit at openjdk.org  Fri Jul 18 17:00:04 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Fri, 18 Jul 2025 17:00:04 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
 <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com>
Message-ID: <WFYY6a3KlciFP1ejLnR7f-hIRumxFATDTzApeP2wKXo=.ad519485-1198-465c-bdea-76d7365c7483@github.com>

On Thu, 17 Jul 2025 07:01:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357445: Remove redundant record_activity calls and leftover initialize call
>>   
>>   - Remove record_activity() from retirement methods as hr_clear() is always last
>>   - Remove leftover initialize() call since initialization moved to constructor
>>   - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1136:
> 
>> 1134:   if (SafepointSynchronize::is_at_safepoint()) {
>> 1135:     shrink(shrink_bytes);
>> 1136:     return true;                     // we *did* something
> 
> (Full) Sentence length comments should follow sentence style: Initial capitalization and full stop at the end. Not sure if the emphasis should be kept, seems to be overused (and I do not think we use it a lot in G1 code).
> (Please no markdown btw :) )

ok. will change as follows:

// pages were at least *requested* to be released ? // Pages were at least requested to be released 

and 

// we *did* something ? // We did something

> src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 64:
> 
>> 62:     // Time-based evaluation only handles uncommit/shrinking, never expansion
>> 63:     if (should_expand) {
>> 64:       log_warning(gc, sizing)("Time-based evaluation unexpected expansion request ignored (resize_amount=%zuB)", resize_amount);
> 
> I think "Time-based evaluation" as a kind of extra tag seems to be too unspecific: Time based evaluation of what?
> 
> I.e. the heap sizing based on GCTimeRatio is also "time-based". Also the messages partially seem to be inconsistent at first glance: Somebody this "time-based" prefix is there, sometimes not. Also sometimes it reads "Time-based evaluation", sometimes "Time-based heap sizing", sometimes having ":" in them, sometimes not.
> 
> If we add an extra tag, that "Time-based*" prefix might be superfluous, particularly if we keep the `sizing`for this kind of stuff (or even make it more specific).

I agree. I started with time-based since I wanted to have a catch-all term for log parsers. But since we also have the `sizing` tag now, I can change the log messages to something more meaningful like "Uncommit evaluation"

> src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 74:
> 
>> 72: //
>> 73: class G1HeapSizingPolicy: public CHeapObj<mtGC> {
>> 74:   static jlong _uncommit_delay_ms;  // Delay before uncommitting inactive regions
> 
> It's generally better to use `Ticks`/`Timespan` etc for times as they a) have higher precision and b) one does not need to carry the unit in them. Just convert when you need. They are also distinct types so that wrong assignment can not happen (like a value containing seconds to something that ought to contain milliseconds).
> One can only round down etc. when needed.
> 
> Also, `jlong` should be avoided, as it is originally a "J"ava type, i.e. for Java interfacing (yeah, it has crept in over time for various reasons).

Great points. Will update to:


Ticks current_ticks = Ticks::now();
Tickspan elapsed = current_ticks - _last_access_ticks;
return elapsed > _uncommit_delay;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2216480242
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2216496524
PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2216439181

From mbeckwit at openjdk.org  Fri Jul 18 16:59:30 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Fri, 18 Jul 2025 16:59:30 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <EqQ-Fr4-JeG1L7_s4wtzmIFkCn0uhJPIM0Ii7ViD-RQ=.56286259-e412-4b23-9569-0c48ddf52ad2@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
 <EqQ-Fr4-JeG1L7_s4wtzmIFkCn0uhJPIM0Ii7ViD-RQ=.56286259-e412-4b23-9569-0c48ddf52ad2@github.com>
Message-ID: <anmaA8T-TygWgAVIFPPbYjdjiN1X3h_5rgvqGn7uOik=.91b8f2dc-97cd-479f-8cdb-3cb49e8787d5@github.com>

On Thu, 17 Jul 2025 15:14:41 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi,
> 
> There appears to be a disconnect between the `get_uncommit_candidates` logic and the actual heap shrinking performed by `G1CollectedHeap::shrink`. While `G1HeapSizingPolicy::evaluate_heap_resize` determines the number of bytes to shrink (via shrink_bytes) and passes this to the heap shrink logic, the regions identified as uncommit candidates are not explicitly communicated or prioritized during the shrink operation.
> 
> As a result, the heap may be shrunk without necessarily uncommitting the specific regions previously marked as uncommit candidates. This can lead to a scenario where those regions remain committed even after the shrink, potentially triggering repeated shrink attempts in subsequent calls to `G1HeapSizingPolicy::evaluate_heap_resize`.
> 
> Is this understanding correct?

Thanks @walulyai - that's a great question! Initially I did have a complicated logic but then I simplified to what we have today. And I have extensive test results to show the integration works perfectly:

**Test Config (Ultra-aggressive settings):**

-XX:G1TimeBasedEvaluationIntervalMillis=3000    # 3s vs 60s default
-XX:G1UncommitDelayMillis=8000                   # 8s vs 300s default  
-XX:G1MinRegionsToUncommit=1                     # 1 vs 10 default
-Xlog:gc+sizing*=trace                           # Every region check
-Xlog:gc+region*=trace                           # All region transitions


**Key Evidence:** Individual operation precision
The smoking gun is the mathematical precision of each individual time-based eval:

Example 1: 336MB operation

[13:41:00] Time-based uncommit: found 248 inactive regions, uncommitting 42 regions (336MB)
[13:41:00] Time-based evaluation: shrinking heap by 336MB
[13:41:00] Heap resize. Requested shrink amount: 352321536B actual shrinking amount: 352321536B (42 regions)

Perfect match: 42 regions calculated = 42 regions removed = 352321536B exactly

Example 2: 168MB Operation

[13:41:15] Time-based uncommit: found 86 inactive regions, uncommitting 21 regions (168MB)
[13:41:15] Time-based evaluation: shrinking heap by 168MB
[13:41:15] Heap resize. Requested shrink amount: 176160768B actual shrinking amount: 176160768B (21 regions)

Perfect match: 21 regions calculated = 21 regions removed = 176160768B exactly

Example 3: 80MB Operation

[13:42:15] Time-based uncommit: found 55 inactive regions, uncommitting 10 regions (80MB)
[13:42:15] Time-based evaluation: shrinking heap by 80MB  
[13:42:15] Heap resize. Requested shrink amount: 83886080B actual shrinking amount: 83886080B (10 regions)

Perfect match: 10 regions calculated = 10 regions removed = 83886080B exactly

Evidence Against "Repeated Shrink Attempts":
`Sequential successful operations: 336MB ? 304MB ? 272MB ? 208MB ? 168MB ? 120MB ? 80MB ? 48MB ? 24MB ? 8MB
Clean termination: [gc,sizing] Time-based evaluation: no heap uncommit needed (evaluation #10)`

Evidence Against "Regions Remaining Committed": Every single operation shows perfect byte-level precision between time-based calculation and G1 execution across 19 consecutive operations with zero failures.

I think this uncomplicated logic works through convergent selection:

1. Time-based logic: Selects empty regions idle > 8 seconds (oldest unused)
2. G1HeapRegionManager::shrink_by(): Decommits from highest region indices (oldest allocated)
3. Natural alignment: In steady workloads, oldest empty regions align with high-index regions

Addressing Your Specific Concerns:

- "Regions remaining committed after shrink": Every operation shows perfect precision (requested bytes = actual bytes, calculated regions = removed regions)
- "Repeated shrink attempts": Clean progression with natural termination when optimal size reached
- "Disconnect between candidate selection and shrinking": I haven't seen this in any of the 100s of the logs that I have processed, so its seems highly improbably given the byte-level precision across all operations

Here are a few complete loop examples:

**Active Uncommitting (336MB):**

[2025-07-18T13:41:00.656+0000][1964552][1964561][info ][gc,sizing      ] Time-based uncommit: found 248 inactive regions, uncommitting 42 regions (336MB)
[2025-07-18T13:41:00.656+0000][1964552][1964561][info ][gc,sizing      ] Time-based evaluation: shrinking heap by 336MB
[2025-07-18T13:41:00.656+0000][1964552][1964562][debug][gc,ergo,heap   ] Heap resize. Requested shrink amount: 352321536B aligned shrink amount: 352321536B
[2025-07-18T13:41:00.657+0000][1964552][1964562][debug][gc,heap,region ] Deactivate regions [361, 389) [339, 353)
[2025-07-18T13:41:00.657+0000][1964552][1964562][debug][gc,ergo,heap   ] Heap resize. Requested shrinking amount: 352321536B actual shrinking amount: 352321536B (42 regions)
[2025-07-18T13:41:00.657+0000][1964552][1964562][info ][gc,heap        ] Heap shrink flagged: uncommitted 42 regions (336MB), heap size now 3048MB


**No Action Needed:**

[2025-07-18T13:42:09.676+0000][1964552][1964561][info ][gc,sizing      ] Time-based uncommit: found 10 inactive regions, uncommitting 2 regions (16MB)
[2025-07-18T13:42:09.676+0000][1964552][1964561][info ][gc,sizing      ] Time-based evaluation: shrinking heap by 16MB
[2025-07-18T13:42:09.676+0000][1964552][1964562][debug][gc,ergo,heap   ] Heap resize. Requested shrink amount: 16777216B actual shrinking amount: 16777216B (2 regions)
[2025-07-18T13:42:09.676+0000][1964552][1964562][info ][gc,heap        ] Heap shrink flagged: uncommitted 2 regions (16MB), heap size now 1440MB
[2025-07-18T13:42:12.676+0000][1964552][1964561][info ][gc,sizing      ] Time-based evaluation: no heap uncommit needed (evaluation #10)


My conclusion is that the architectural separation exists by design (time-based logic calculates, G1 executes), but the byte-level mathematical precision across 19 consecutive operations proves zero practical disconnect. The convergent selection patterns ensure perfect alignment between time-based candidate identification and G1's actual uncommitting.

**Supporting Evidence:** 2,975 total candidate events processed across the test run with 100% success rate and perfect mathematical alignment in every operation.

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

PR Comment: https://git.openjdk.org/jdk/pull/26240#issuecomment-3089942779

From mbeckwit at openjdk.org  Fri Jul 18 17:00:19 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Fri, 18 Jul 2025 17:00:19 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <Ny2TNW-yZD1dZUVZBsmhVJyMe-J0p5oFLzi7GOV6eYI=.2fde56d9-17aa-4a23-9100-1e8dc6007d98@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <lTL6bcwut0XPTgERHPwxA4Jx5BiZn6Ptarg0-Se6PK4=.733e88e0-d15a-459e-83e1-f438bd1b0cb4@github.com>
 <CSOjoeGEQpw0czzgFy04TE44TipPWaDamF6UwOVPaRA=.45c7c817-64be-4256-b03e-6d6c5b57eb4c@github.com>
 <Ny2TNW-yZD1dZUVZBsmhVJyMe-J0p5oFLzi7GOV6eYI=.2fde56d9-17aa-4a23-9100-1e8dc6007d98@github.com>
Message-ID: <qJDOaQM7CCf0S2gh71XoHGwktQHV523mYedhEOTrclg=.78c09503-d75a-477d-bf56-616e190a0ff2@github.com>

On Wed, 16 Jul 2025 21:47:33 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 931:
>> 
>>> 929:   G1Policy* policy() const { return _policy; }
>>> 930:   // The heap sizing policy.
>>> 931:   G1HeapSizingPolicy* heap_sizing_policy() const { return _heap_sizing_policy; }
>> 
>> unused method, probably not needed.
>
> I double-checked and I think it is needed. I will do a local build and try without it instead of removing it and get back to you.

will remove it as its not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2216436795

From tschatzl at openjdk.org  Fri Jul 18 17:00:25 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 18 Jul 2025 17:00:25 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v4]
In-Reply-To: <sbO5a6uPe6d2fjv0VmS2lEKJ8kKhDAdPVPGAf5amDUY=.10436ad6-3539-4a51-8f4f-7c972370d63f@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <sbO5a6uPe6d2fjv0VmS2lEKJ8kKhDAdPVPGAf5amDUY=.10436ad6-3539-4a51-8f4f-7c972370d63f@github.com>
Message-ID: <E5iigXAuwvKNjRPjOqseYIR6EKVEw0Jl5bBS3nR2zns=.db41093d-bebb-4541-8eb6-5aa52589847c@github.com>

On Fri, 18 Jul 2025 11:51:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into 8350621-code-cache-mgmt-hang
>  - * kbarrett-review
>  - Merge branch 'master' into 8350621-code-cache-mgmt-hang
>  - * more refactoring, comments
>  - * kbarrett review part 2 (slightly incomplete)
>  - * kbarrett review - 1
>  - * initial kbarrett refactoring
>  - * kbarret review:
>      - restructure code in `try_collect_concurrently`
>      - fix asserts - they only worked in the test because of whitebox being active
>      - fix comments
>    * threalmdoerr review:
>      - fix test to be more lenient
>  - * some whitespace fixes
>  - 8350621
>    
>    Hi all,
>    
>      please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>    
>    In particular, G1 does not make sure when its `collect()` method is called during a
>    concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs
>    after that request. This makes it so that some internal flag is not reset appropriately,
>    stuck until the next code unloading (caused by e.g. a regular concurrent cycle being
>    triggered).
>    
>    Testing: tier1-5
>    
>    Thanks,
>      Thomas

Tier 1-5 rerun almost complete seems to be okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/26189#issuecomment-3089935962

From mbeckwit at openjdk.org  Fri Jul 18 17:56:43 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Fri, 18 Jul 2025 17:56:43 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
 <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com>
Message-ID: <Wae-djEduC53iC4UhfjJmG2VQUX48xNb-FN7-FzBtyI=.a0476e3d-08bf-4c2a-8a1f-ba64969d2332@github.com>

On Thu, 17 Jul 2025 07:08:57 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357445: Remove redundant record_activity calls and leftover initialize call
>>   
>>   - Remove record_activity() from retirement methods as hr_clear() is always last
>>   - Remove leftover initialize() call since initialization moved to constructor
>>   - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap
>
> src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 544:
> 
>> 542:     size_t max_shrink_bytes = current_heap > min_heap ? current_heap - min_heap : 0;
>> 543: 
>> 544:     log_trace(gc, sizing)("Time-based evaluation details: current_heap=%zuB min_heap=%zuB "
> 
> I do not think `trace`log messages need the "details" in `Time-based evaluation details" - this is already indicated by the log level.
> 
> Also, in contrast to other "Time-based evaluation" messages this has a ":" at the end, which is inconsistent.

ok changed to:
log_trace(gc, sizing)("Uncommit evaluation: current_heap=%zuB min_heap=%zuB ...")

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2216604414

From duke at openjdk.org  Sat Jul 19 10:49:53 2025
From: duke at openjdk.org (Lei Zhu)
Date: Sat, 19 Jul 2025 10:49:53 GMT
Subject: RFR: 8362532: Test gc/g1/plab/* duplicate command-line options
Message-ID: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>

Just removed duplicate flag, no other changes.

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

Commit messages:
 - 8362532: Test gc/g1/plab/* duplicate command-line options

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

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

From kbarrett at openjdk.org  Sun Jul 20 02:13:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 20 Jul 2025 02:13:52 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v4]
In-Reply-To: <sbO5a6uPe6d2fjv0VmS2lEKJ8kKhDAdPVPGAf5amDUY=.10436ad6-3539-4a51-8f4f-7c972370d63f@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <sbO5a6uPe6d2fjv0VmS2lEKJ8kKhDAdPVPGAf5amDUY=.10436ad6-3539-4a51-8f4f-7c972370d63f@github.com>
Message-ID: <PBZgUlosBSNB5pqK3kw93RCuS7Un-PW0qS92Eg50acA=.ca768048-a5d3-46e7-9be2-7e7153aeb12e@github.com>

On Fri, 18 Jul 2025 11:51:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into 8350621-code-cache-mgmt-hang
>  - * kbarrett-review
>  - Merge branch 'master' into 8350621-code-cache-mgmt-hang
>  - * more refactoring, comments
>  - * kbarrett review part 2 (slightly incomplete)
>  - * kbarrett review - 1
>  - * initial kbarrett refactoring
>  - * kbarret review:
>      - restructure code in `try_collect_concurrently`
>      - fix asserts - they only worked in the test because of whitebox being active
>      - fix comments
>    * threalmdoerr review:
>      - fix test to be more lenient
>  - * some whitespace fixes
>  - 8350621
>    
>    Hi all,
>    
>      please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>    
>    In particular, G1 does not make sure when its `collect()` method is called during a
>    concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs
>    after that request. This makes it so that some internal flag is not reset appropriately,
>    stuck until the next code unloading (caused by e.g. a regular concurrent cycle being
>    triggered).
>    
>    Testing: tier1-5
>    
>    Thanks,
>      Thomas

Almost...

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1894:

> 1892:              cause == GCCause::_wb_breakpoint ||
> 1893:              cause == GCCause::_java_lang_system_gc ||
> 1894:              cause == GCCause::_dcmd_gc_run, "Unsupported cause %s", GCCause::to_string(cause));

My suggestion was to only check for the first 2 of these, as they are the only
ones not (currently) covered elsewhere and prevented from getting here. Any
causes other than those two would be surprising here.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26189#pullrequestreview-3035656371
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2217531120

From tschatzl at openjdk.org  Sun Jul 20 11:11:43 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Sun, 20 Jul 2025 11:11:43 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v4]
In-Reply-To: <PBZgUlosBSNB5pqK3kw93RCuS7Un-PW0qS92Eg50acA=.ca768048-a5d3-46e7-9be2-7e7153aeb12e@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <sbO5a6uPe6d2fjv0VmS2lEKJ8kKhDAdPVPGAf5amDUY=.10436ad6-3539-4a51-8f4f-7c972370d63f@github.com>
 <PBZgUlosBSNB5pqK3kw93RCuS7Un-PW0qS92Eg50acA=.ca768048-a5d3-46e7-9be2-7e7153aeb12e@github.com>
Message-ID: <pkl2xnKqXagtaL7j9Wg2oWgJw0bl_dcC1mVPmXNHakA=.4c62611b-91a2-4f99-83b4-f82d7e1a1c84@github.com>

On Sun, 20 Jul 2025 01:56:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'master' into 8350621-code-cache-mgmt-hang
>>  - * kbarrett-review
>>  - Merge branch 'master' into 8350621-code-cache-mgmt-hang
>>  - * more refactoring, comments
>>  - * kbarrett review part 2 (slightly incomplete)
>>  - * kbarrett review - 1
>>  - * initial kbarrett refactoring
>>  - * kbarret review:
>>      - restructure code in `try_collect_concurrently`
>>      - fix asserts - they only worked in the test because of whitebox being active
>>      - fix comments
>>    * threalmdoerr review:
>>      - fix test to be more lenient
>>  - * some whitespace fixes
>>  - 8350621
>>    
>>    Hi all,
>>    
>>      please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>>    
>>    In particular, G1 does not make sure when its `collect()` method is called during a
>>    concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs
>>    after that request. This makes it so that some internal flag is not reset appropriately,
>>    stuck until the next code unloading (caused by e.g. a regular concurrent cycle being
>>    triggered).
>>    
>>    Testing: tier1-5
>>    
>>    Thanks,
>>      Thomas
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1894:
> 
>> 1892:              cause == GCCause::_wb_breakpoint ||
>> 1893:              cause == GCCause::_java_lang_system_gc ||
>> 1894:              cause == GCCause::_dcmd_gc_run, "Unsupported cause %s", GCCause::to_string(cause));
> 
> My suggestion was to only check for the first 2 of these, as they are the only
> ones not (currently) covered elsewhere and prevented from getting here. Any
> causes other than those two would be surprising here.

I somehow thought they would end up here with `-XX:+ExplicitGCInvokesConcurrent`, but you are right after thinking again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2217766027

From tschatzl at openjdk.org  Mon Jul 21 07:25:06 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 21 Jul 2025 07:25:06 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v5]
In-Reply-To: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
Message-ID: <4N9-BLnESnMl_bWCbSju1JNqaodmtKKbelBPPC53o9c=.3cd41647-d22f-41a1-b2f9-b78171722727@github.com>

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

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

  * kbarrett review, remove unsupported gc causes for that branch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26189/files
  - new: https://git.openjdk.org/jdk/pull/26189/files/9b2ea952..ba85553b

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

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

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

From tschatzl at openjdk.org  Mon Jul 21 07:52:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 21 Jul 2025 07:52:44 GMT
Subject: RFR: 8362532: Test gc/g1/plab/* duplicate command-line options
In-Reply-To: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>
References: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>
Message-ID: <QgZx2WrHU5lJlNtr_nQYydxNQVLJT7rIg3TIpFxlt9M=.ca1bcd14-404b-4c4c-bf15-21fb9e900da8@github.com>

On Sat, 19 Jul 2025 10:44:41 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Just removed duplicate flag, no other changes.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26402#pullrequestreview-3036939464

From duke at openjdk.org  Mon Jul 21 08:29:19 2025
From: duke at openjdk.org (duke)
Date: Mon, 21 Jul 2025 08:29:19 GMT
Subject: RFR: 8362532: Test gc/g1/plab/* duplicate command-line options
In-Reply-To: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>
References: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>
Message-ID: <9ngc0jxWxQfUPlEBnGFgToYQLKcM0UqJG0NA-X5_PIc=.b7de0c15-0510-4fb3-88d0-ea628927d615@github.com>

On Sat, 19 Jul 2025 10:44:41 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Just removed duplicate flag, no other changes.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26402#issuecomment-3095708884

From duke at openjdk.org  Mon Jul 21 08:29:19 2025
From: duke at openjdk.org (Lei Zhu)
Date: Mon, 21 Jul 2025 08:29:19 GMT
Subject: RFR: 8362532: Test gc/g1/plab/* duplicate command-line options
 [v2]
In-Reply-To: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>
References: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>
Message-ID: <cmN8nslWFWleJl5jVFx3SedH4ftxXocETyyBzu0OoXc=.420115d9-19d0-473c-b837-40e69a125f82@github.com>

> Just removed duplicate flag, no other changes.

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

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26402/files
  - new: https://git.openjdk.org/jdk/pull/26402/files/05ebf938..f956ca91

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

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

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

From ayang at openjdk.org  Mon Jul 21 10:02:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 21 Jul 2025 10:02:50 GMT
Subject: RFR: 8362532: Test gc/g1/plab/* duplicate command-line options
 [v2]
In-Reply-To: <cmN8nslWFWleJl5jVFx3SedH4ftxXocETyyBzu0OoXc=.420115d9-19d0-473c-b837-40e69a125f82@github.com>
References: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>
 <cmN8nslWFWleJl5jVFx3SedH4ftxXocETyyBzu0OoXc=.420115d9-19d0-473c-b837-40e69a125f82@github.com>
Message-ID: <bQ3IOuv6P6Q8kj4dNH_DIxK44fmX1kGLa7JyT-md4iU=.1fceb785-711f-4d04-b9a7-d1e89516d97a@github.com>

On Mon, 21 Jul 2025 08:29:19 GMT, Lei Zhu <duke at openjdk.org> wrote:

>> Just removed duplicate flag, no other changes.
>
> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26402#pullrequestreview-3037334673

From duke at openjdk.org  Mon Jul 21 10:02:51 2025
From: duke at openjdk.org (Lei Zhu)
Date: Mon, 21 Jul 2025 10:02:51 GMT
Subject: Integrated: 8362532: Test gc/g1/plab/* duplicate command-line options
In-Reply-To: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>
References: <diuO_FUy7KtpqTYv8l0XNXhzQvnjeBOMvQBz5hgj0FQ=.2a713d2c-8dd5-45d8-9fa2-719a13e68bdf@github.com>
Message-ID: <0xJAH8jyfVGDAjnVvk2YJdEXvLoKkuKl3GTbWPprieg=.34c94a2b-9334-45e6-9a60-1c11e36ec6cc@github.com>

On Sat, 19 Jul 2025 10:44:41 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Just removed duplicate flag, no other changes.

This pull request has now been integrated.

Changeset: 13bab09b
Author:    Lei Zhu <korov9.c at gmail.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13bab09bffc411dde324599c2e15852ef4b53d55
Stats:     9 lines in 2 files changed: 0 ins; 3 del; 6 mod

8362532: Test gc/g1/plab/* duplicate command-line options

Reviewed-by: tschatzl, ayang

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

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

From wkemper at openjdk.org  Mon Jul 21 18:30:26 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 21 Jul 2025 18:30:26 GMT
Subject: RFR: 8350050: Shenandoah: Disable and purge allocation pacing
 support [v2]
In-Reply-To: <djw4zXuHgI9245b08giMWPOHrqJmuzlYd7CJxkRCIEk=.8548da0c-2c40-44a7-a120-862f44f1dd63@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
 <djw4zXuHgI9245b08giMWPOHrqJmuzlYd7CJxkRCIEk=.8548da0c-2c40-44a7-a120-862f44f1dd63@github.com>
Message-ID: <8IbfMVwM1KmksUqx0XM8WvDFUDoIh-hKVvES012nBu0=.b48aec7f-856d-42cb-a297-59b555111342@github.com>

On Fri, 18 Jul 2025 00:54:19 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, have been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational Sh
 enandoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
>> 
>> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
>> 
>> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
>> 
>> 
>> ### SpecJBB
>> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
>> 
>>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
>> --------------------------|--------------------|----------------------------------|
>> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
>> -ShenandoahPacing          |              24.8            |                               *26.9*                |
>> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
>> 
>> ### Testing:
>> - SPECjbb
>> - Code ...
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove some dangling references and unused variables identified in the
>   code review.

Thanks for the changes. LGTM.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24002#pullrequestreview-3039244754

From kbarrett at openjdk.org  Mon Jul 21 20:00:40 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 21 Jul 2025 20:00:40 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v5]
In-Reply-To: <4N9-BLnESnMl_bWCbSju1JNqaodmtKKbelBPPC53o9c=.3cd41647-d22f-41a1-b2f9-b78171722727@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <4N9-BLnESnMl_bWCbSju1JNqaodmtKKbelBPPC53o9c=.3cd41647-d22f-41a1-b2f9-b78171722727@github.com>
Message-ID: <sv24fRrDxkjVafY2NOzE36W_DorjIOqlqfkJ6tHdZpA=.28ce0fe5-baac-4ab0-8a23-81184e8ff37d@github.com>

On Mon, 21 Jul 2025 07:25:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * kbarrett review, remove unsupported gc causes for that branch

Still not quite...

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1892:

> 1890:       assert(cause == GCCause::_g1_humongous_allocation ||
> 1891:              cause == GCCause::_g1_periodic_collection ||
> 1892:              cause == GCCause::_wb_breakpoint, "Unsupported cause %s", GCCause::to_string(cause));

`_wb_breakpoint` is unexpected here too, since it's completely handled by an earlier clause in the if-ladder.
The first two are the entire residue that should be able to get here.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26189#pullrequestreview-3039578093
PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2220169890

From tschatzl at openjdk.org  Tue Jul 22 06:59:10 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 22 Jul 2025 06:59:10 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v6]
In-Reply-To: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
Message-ID: <56Md8gVkunj4tfyMYyasTXVCYOTVfkXW5S7rTi9Khvs=.022a504d-67f5-413a-9c5b-e05d196b3285@github.com>

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

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

  * kbarret review, remove wb_breakpoint from possible cases where we can ignore the request if a concurrent mark is already running

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26189/files
  - new: https://git.openjdk.org/jdk/pull/26189/files/ba85553b..16aa539c

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

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

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

From tschatzl at openjdk.org  Tue Jul 22 07:15:25 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 22 Jul 2025 07:15:25 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v5]
In-Reply-To: <sv24fRrDxkjVafY2NOzE36W_DorjIOqlqfkJ6tHdZpA=.28ce0fe5-baac-4ab0-8a23-81184e8ff37d@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <4N9-BLnESnMl_bWCbSju1JNqaodmtKKbelBPPC53o9c=.3cd41647-d22f-41a1-b2f9-b78171722727@github.com>
 <sv24fRrDxkjVafY2NOzE36W_DorjIOqlqfkJ6tHdZpA=.28ce0fe5-baac-4ab0-8a23-81184e8ff37d@github.com>
Message-ID: <dGnpPNAmVqXb4bZZaDcILxwuQWMPdYzFGRbH4xx1kqk=.50d1d37e-b7f8-4b5e-ad17-824f85d7b53a@github.com>

On Mon, 21 Jul 2025 19:57:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * kbarrett review, remove unsupported gc causes for that branch
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1892:
> 
>> 1890:       assert(cause == GCCause::_g1_humongous_allocation ||
>> 1891:              cause == GCCause::_g1_periodic_collection ||
>> 1892:              cause == GCCause::_wb_breakpoint, "Unsupported cause %s", GCCause::to_string(cause));
> 
> `_wb_breakpoint` is unexpected here too, since it's completely handled by an earlier clause in the if-ladder.
> The first two are the entire residue that should be able to get here.

fixed. Thanks for pointing this out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26189#discussion_r2221452773

From shade at openjdk.org  Tue Jul 22 08:48:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 08:48:29 GMT
Subject: RFR: 8350050: Shenandoah: Disable and purge allocation pacing
 support [v2]
In-Reply-To: <djw4zXuHgI9245b08giMWPOHrqJmuzlYd7CJxkRCIEk=.8548da0c-2c40-44a7-a120-862f44f1dd63@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
 <djw4zXuHgI9245b08giMWPOHrqJmuzlYd7CJxkRCIEk=.8548da0c-2c40-44a7-a120-862f44f1dd63@github.com>
Message-ID: <Q5ju4vhfJHWnB2UT2UbmAqorl2yFZg4cyp71TtVGpZ8=.b5687f57-ab9a-42ca-910e-7c42f83f03a1@github.com>

On Fri, 18 Jul 2025 00:54:19 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, have been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational Sh
 enandoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
>> 
>> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
>> 
>> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
>> 
>> 
>> ### SpecJBB
>> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
>> 
>>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
>> --------------------------|--------------------|----------------------------------|
>> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
>> -ShenandoahPacing          |              24.8            |                               *26.9*                |
>> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
>> 
>> ### Testing:
>> - SPECjbb
>> - Code ...
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove some dangling references and unused variables identified in the
>   code review.

The removal looks clean, thanks!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24002#pullrequestreview-3041888398

From ayang at openjdk.org  Tue Jul 22 10:15:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 22 Jul 2025 10:15:03 GMT
Subject: RFR: 8363229: Parallel: Remove develop flag
 GCExpandToAllocateDelayMillis
Message-ID: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>

Simple removing a develop flag that is rarely (or even never) used.

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

Commit messages:
 - pgc-remove-dev-flag

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

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

From shade at openjdk.org  Tue Jul 22 10:18:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 10:18:23 GMT
Subject: RFR: 8363229: Parallel: Remove develop flag
 GCExpandToAllocateDelayMillis
In-Reply-To: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
References: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
Message-ID: <MxkHAal7KB01BahsBv3SLPC-VxMWMyPp0m_EbWfO3DU=.886a1604-29d5-4b8d-8f82-29e131585526@github.com>

On Tue, 22 Jul 2025 10:09:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing a develop flag that is rarely (or even never) used.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26425#pullrequestreview-3042291664

From shade at openjdk.org  Tue Jul 22 10:24:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 10:24:36 GMT
Subject: RFR: 8363229: Parallel: Remove develop flag
 GCExpandToAllocateDelayMillis
In-Reply-To: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
References: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
Message-ID: <iHX3CmGDed9j1XpH6YDwg5pCcSafIjiIvav13YOJJNo=.4ba79353-4f96-4ef0-879f-49f02d5c70d2@github.com>

On Tue, 22 Jul 2025 10:09:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing a develop flag that is rarely (or even never) used.

This is trivial, IMO, as long as builds pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/26425#issuecomment-3102085004

From tschatzl at openjdk.org  Tue Jul 22 10:43:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 22 Jul 2025 10:43:27 GMT
Subject: RFR: 8363229: Parallel: Remove develop flag
 GCExpandToAllocateDelayMillis
In-Reply-To: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
References: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
Message-ID: <OAUkw-Pxe5xLu8HrFwa6ucUvdM_UTbOpXvFDFschJ0c=.169f3599-cd76-481e-b739-e51a5e79844a@github.com>

On Tue, 22 Jul 2025 10:09:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing a develop flag that is rarely (or even never) used.

Lgtm and trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26425#pullrequestreview-3042420982

From ayang at openjdk.org  Tue Jul 22 13:32:31 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 22 Jul 2025 13:32:31 GMT
Subject: RFR: 8363229: Parallel: Remove develop flag
 GCExpandToAllocateDelayMillis
In-Reply-To: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
References: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
Message-ID: <pYA2i15OPzz8T1LMM42n8T3NOtNJei4SDzv53wgyGrI=.723946ef-8833-4a01-bd15-2cc1c1739a73@github.com>

On Tue, 22 Jul 2025 10:09:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing a develop flag that is rarely (or even never) used.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26425#issuecomment-3102717993

From ayang at openjdk.org  Tue Jul 22 13:32:31 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 22 Jul 2025 13:32:31 GMT
Subject: Integrated: 8363229: Parallel: Remove develop flag
 GCExpandToAllocateDelayMillis
In-Reply-To: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
References: <KXmF1WnmU74EDbKphpoz-Dz8rrrqhbHf2jrjxTgdu4Y=.1c1c0b24-6fa6-43a1-9548-fc115234d128@github.com>
Message-ID: <3R0h90ZA4ZtT2U23Ftx_6S91cYoXhEBUTpW0G31-icw=.ac4fd111-e3e2-4231-a9c2-706b57d9b029@github.com>

On Tue, 22 Jul 2025 10:09:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing a develop flag that is rarely (or even never) used.

This pull request has now been integrated.

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

8363229: Parallel: Remove develop flag GCExpandToAllocateDelayMillis

Reviewed-by: shade, tschatzl

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

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

From kdnilsen at openjdk.org  Tue Jul 22 17:41:56 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 22 Jul 2025 17:41:56 GMT
Subject: RFR: 8350050: Shenandoah: Disable and purge allocation pacing
 support [v2]
In-Reply-To: <djw4zXuHgI9245b08giMWPOHrqJmuzlYd7CJxkRCIEk=.8548da0c-2c40-44a7-a120-862f44f1dd63@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
 <djw4zXuHgI9245b08giMWPOHrqJmuzlYd7CJxkRCIEk=.8548da0c-2c40-44a7-a120-862f44f1dd63@github.com>
Message-ID: <gPylNr_RH7QZdJ_j7Om8ofW_5tQs8RtPvDeyPzzI5Ao=.50d02e7e-6328-4112-ab0b-e1424d235c00@github.com>

On Fri, 18 Jul 2025 00:54:19 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, have been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational Sh
 enandoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
>> 
>> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
>> 
>> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
>> 
>> 
>> ### SpecJBB
>> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
>> 
>>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
>> --------------------------|--------------------|----------------------------------|
>> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
>> -ShenandoahPacing          |              24.8            |                               *26.9*                |
>> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
>> 
>> ### Testing:
>> - SPECjbb
>> - Code ...
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove some dangling references and unused variables identified in the
>   code review.

Thanks for this cleanup.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24002#pullrequestreview-3044142996

From kdnilsen at openjdk.org  Tue Jul 22 17:44:55 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 22 Jul 2025 17:44:55 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
In-Reply-To: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
Message-ID: <kkE84NBuKkvlLmUQL8MDAOvRFpF1MoFC5YhnZCotnwU=.612a7f3d-fa7c-49a9-a96a-604b8313f781@github.com>

On Wed, 9 Jul 2025 17:52:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah has `product only` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.

Thanks. This instrumentation is helpful in evaluating further proposed changes.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26222#pullrequestreview-3044153951

From kdnilsen at openjdk.org  Tue Jul 22 17:50:56 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 22 Jul 2025 17:50:56 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
Message-ID: <YATZkNzTb3duY0o_Q_agGt-fA2CjxLJ6gddnCsedhBM=.14a2c482-814e-4093-b41f-646473d5be99@github.com>

On Fri, 11 Jul 2025 18:24:56 GMT, Rui Li <duke at openjdk.org> wrote:

> Add logging for Shenandoah as well as Generational Shenandoah. 
> 
> Log samples:
> 
> 
> ######################################
> Before gc
> ######################################
> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.231s][debug][gc,heap      ] GC(0) 
> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> 
> 
> 
> ######################################
> After gc
> ######################################
> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
> [2.067s][debug][gc,heap        ] GC(11) 
> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

Thanks for this contribution.  I concur with suggestions from @ysramakrishna.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26272#pullrequestreview-3044179696

From ysr at openjdk.org  Tue Jul 22 21:21:08 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 22 Jul 2025 21:21:08 GMT
Subject: RFR: 8350050: Shenandoah: Disable and purge allocation pacing
 support [v3]
In-Reply-To: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
Message-ID: <L2QzCEW53GLCW9iyk4FvNBNJAibr4u9Qt2i7CwMFXy8=.a5f461a9-f8d1-4f30-9f30-dad1cb9af8c5@github.com>

> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, have been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational She
 nandoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
> 
> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
> 
> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
> 
> 
> ### SpecJBB
> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
> 
>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
> --------------------------|--------------------|----------------------------------|
> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
> -ShenandoahPacing          |              24.8            |                               *26.9*                |
> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
> 
> ### Testing:
> - SPECjbb
> - Code Pipeline Stress
> - Perf Dashboard
> -----...

Y. Srinivas Ramakrishna has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into pacing
 - Remove some dangling references and unused variables identified in the
   code review.
 - Fix some comments and user instructions / documentation that refer to
   the now removed pacing feature.
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - ... and 8 more: https://git.openjdk.org/jdk/compare/ea6674fe...3fd09b94

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

Changes: https://git.openjdk.org/jdk/pull/24002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24002&range=02
  Stats: 786 lines in 20 files changed: 0 ins; 779 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24002/head:pull/24002

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

From ysr at openjdk.org  Wed Jul 23 00:27:01 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 23 Jul 2025 00:27:01 GMT
Subject: RFR: 8350050: Shenandoah: Disable and purge allocation pacing
 support [v3]
In-Reply-To: <L2QzCEW53GLCW9iyk4FvNBNJAibr4u9Qt2i7CwMFXy8=.a5f461a9-f8d1-4f30-9f30-dad1cb9af8c5@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
 <L2QzCEW53GLCW9iyk4FvNBNJAibr4u9Qt2i7CwMFXy8=.a5f461a9-f8d1-4f30-9f30-dad1cb9af8c5@github.com>
Message-ID: <qXN1l76iZLnHARFLLMtG1nXq50fWjN9hXBtjXYtki74=.f3d6d536-7015-4111-ad34-de448c084a3c@github.com>

On Tue, 22 Jul 2025 21:21:08 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, have been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational Sh
 enandoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
>> 
>> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
>> 
>> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
>> 
>> 
>> ### SpecJBB
>> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
>> 
>>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
>> --------------------------|--------------------|----------------------------------|
>> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
>> -ShenandoahPacing          |              24.8            |                               *26.9*                |
>> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
>> 
>> ### Testing:
>> - SPECjbb
>> - Code ...
>
> Y. Srinivas Ramakrishna has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into pacing
>  - Remove some dangling references and unused variables identified in the
>    code review.
>  - Fix some comments and user instructions / documentation that refer to
>    the now removed pacing feature.
>  - Merge branch 'master' into pacing
>  - Merge branch 'master' into pacing
>  - Merge branch 'master' into pacing
>  - Merge branch 'master' into pacing
>  - Merge branch 'master' into pacing
>  - Merge branch 'master' into pacing
>  - Merge branch 'master' into pacing
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/ea6674fe...3fd09b94

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24002#issuecomment-3105224985

From ysr at openjdk.org  Wed Jul 23 00:27:02 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 23 Jul 2025 00:27:02 GMT
Subject: Integrated: 8350050: Shenandoah: Disable and purge allocation pacing
 support
In-Reply-To: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
Message-ID: <P_ounnsE0woYcjmaVPdf1iVJWpW2bBgVBS29fmaRvnQ=.24d0fd8e-0e77-4cc2-9b1f-247fff5f1158@github.com>

On Wed, 12 Mar 2025 01:11:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, have been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational She
 nandoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
> 
> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
> 
> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
> 
> 
> ### SpecJBB
> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
> 
>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
> --------------------------|--------------------|----------------------------------|
> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
> -ShenandoahPacing          |              24.8            |                               *26.9*                |
> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
> 
> ### Testing:
> - SPECjbb
> - Code Pipeline Stress
> - Perf Dashboard
> -----...

This pull request has now been integrated.

Changeset: 79f9d8d8
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79f9d8d832a589b74cc014289ef84a1efe529468
Stats:     786 lines in 20 files changed: 0 ins; 779 del; 7 mod

8350050: Shenandoah: Disable and purge allocation pacing support

Reviewed-by: wkemper, shade, kdnilsen

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

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

From ysr at openjdk.org  Wed Jul 23 01:41:55 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 23 Jul 2025 01:41:55 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
In-Reply-To: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
Message-ID: <ERrHXU5sLCOODE76903yuq-93ZVeqaakDj0DA_uuS70=.a928b2ee-2c78-4f1b-8be1-896fbbebf38a@github.com>

On Wed, 9 Jul 2025 17:52:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah has `product only` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.

Approved, modulo a few nits.

The extra detail is useful!

> Shenandoah has `product only` instrumentation to track evacuation performance.

Did you mean to say `non-product` instead of `product only` above?

src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.cpp line 112:

> 110:   st->print("Young: "); _young.print_on(st);
> 111:   st->print("Old: "); _old.print_on(st);
> 112:   st->print("Promotion: "); _promotion.print_on(st);

Nit: I might switch the order of Promote & Old.

src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.hpp line 78:

> 76: 
> 77:   void begin_evacuation(size_t bytes, ShenandoahAffiliation from, ShenandoahAffiliation to);
> 78:   void end_evacuation(size_t bytes, ShenandoahAffiliation from, ShenandoahAffiliation to);

1 line documentation comment for each, please.

src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.hpp line 101:

> 99: 
> 100:   void begin_evacuation(Thread* thread, size_t bytes, ShenandoahAffiliation from, ShenandoahAffiliation to);
> 101:   void end_evacuation(Thread* thread, size_t bytes, ShenandoahAffiliation from, ShenandoahAffiliation to);

1 line documentation comment for each, please.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26222#pullrequestreview-3045297809
PR Review Comment: https://git.openjdk.org/jdk/pull/26222#discussion_r2224126864
PR Review Comment: https://git.openjdk.org/jdk/pull/26222#discussion_r2224124878
PR Review Comment: https://git.openjdk.org/jdk/pull/26222#discussion_r2224125359

From kbarrett at openjdk.org  Wed Jul 23 02:06:07 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Jul 2025 02:06:07 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v6]
In-Reply-To: <56Md8gVkunj4tfyMYyasTXVCYOTVfkXW5S7rTi9Khvs=.022a504d-67f5-413a-9c5b-e05d196b3285@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <56Md8gVkunj4tfyMYyasTXVCYOTVfkXW5S7rTi9Khvs=.022a504d-67f5-413a-9c5b-e05d196b3285@github.com>
Message-ID: <CHwdyKs2RFTyqpvD5nhlxY8xXlN2foUh1L1aLE-ASbo=.c95cb11e-dab6-4a35-8785-cbb21fdde59a@github.com>

On Tue, 22 Jul 2025 06:59:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * kbarret review, remove wb_breakpoint from possible cases where we can ignore the request if a concurrent mark is already running

Looks good, except for possible formatting nit.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26189#pullrequestreview-3045338248

From manc at openjdk.org  Wed Jul 23 07:18:57 2025
From: manc at openjdk.org (Man Cao)
Date: Wed, 23 Jul 2025 07:18:57 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
Message-ID: <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>

On Thu, 17 Jul 2025 13:16:29 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included.
>> 
>> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing.  Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios.
>> 
>> Testing: Tier 1
>
> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - cleanup after merge
>  - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact
>  - Merge branch 'NormalizeTiming' into ConcCPUImpact
>  - Thomas suggestion
>  - Thomas Review
>  - reorder
>  - concurrent gc impact
>  - clean out
>  - init

src/hotspot/share/gc/g1/g1Analytics.cpp line 173:

> 171:   // activity. We do not account for contention on other shared resources such as memory bandwidth and
> 172:   // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
> 173:   uint num_cpus = (uint)os::active_processor_count();

It is a good idea to convert CPU time to wall-clock time "lost" by mutator threads. However, it could be challenging in some environments. E.g. a background controller process that periodically runs `taskset` to change CPU affinity mask for the Java process, leading to `os::active_processor_count()` returning variable values.
Another scenario is that the Java process runs in a CPU-constraint container, but for some reasons has to run with `-XX:-UseContainerSupport`. Then all of `os::active_processor_count()`, `ConcGCThreads`, `ParallelGCThreads` could be much higher than the max # of available CPU cores.

Our internal infra has both issues above, and I don't have a good idea to mitigate them in G1. I think the current approach is acceptable: due to the latter `-XX:-UseContainerSupport` issue, it will mostly lead to under-counting concurrent GC CPU time, which is not a show stopper.

src/hotspot/share/gc/g1/g1Analytics.cpp line 174:

> 172:   // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
> 173:   uint num_cpus = (uint)os::active_processor_count();
> 174:   num_cpus = MIN2(num_cpus, MAX2(ConcGCThreads, ParallelGCThreads));

A minor issue is that `UseDynamicNumberOfGCThreads` may not activate all `ConcGCThreads`. I think it is acceptable the wall-clock time "lost" by mutator threads is a best-effort approximation anyway.

src/hotspot/share/gc/g1/g1Policy.cpp line 678:

> 676:   double cur_gc_cpu_time_ms = _g1h->elapsed_gc_cpu_time() * MILLIUNITS;
> 677: 
> 678:   double concurrent_gc_cpu_time_ms = cur_gc_cpu_time_ms - prev_gc_cpu_pause_end_ms;

`CollectedHeap::elapsed_gc_cpu_time()` includes  `_vmthread_cpu_time` and `string_dedup_cpu_time`. Should we exclude VM threads and StringDedup threads' CPU time from `concurrent_gc_cpu_time_ms`? Otherwise non-GC activities could affect G1's heap sizing decisions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2224597028
PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2224629012
PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2224541165

From manc at openjdk.org  Wed Jul 23 07:18:58 2025
From: manc at openjdk.org (Man Cao)
Date: Wed, 23 Jul 2025 07:18:58 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v2]
In-Reply-To: <my5rl32VDZwyyMr5clKQB9LSJi7DzwB7Kzsy1Du_XgA=.183e915a-1a89-49e5-86eb-255153990083@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <K48H6KBuQwG7kDdgjeY36LzFozkwyxrfyd0YRZt6Q2I=.3e68e23e-9b1c-4da3-abbd-e4603eb2e2f2@github.com>
 <my5rl32VDZwyyMr5clKQB9LSJi7DzwB7Kzsy1Du_XgA=.183e915a-1a89-49e5-86eb-255153990083@github.com>
Message-ID: <eh8DhMMlx96Ixor96BXYo_gr47E3SLWJlmPuuc4BSx4=.98099d22-588e-4e95-81b2-86d6b61aab70@github.com>

On Thu, 17 Jul 2025 12:36:39 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Analytics.cpp line 174:
>> 
>>> 172:   // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
>>> 173:   uint num_cpus = (uint)os::active_processor_count();
>>> 174:   num_cpus = MIN2(num_cpus, MAX2(ConcGCThreads, ParallelGCThreads));
>> 
>> Why the use of `ParallelGCThreads`? I thought parallel-threads are used only for stw-work but the current context about concurrent-work.
>
> `G1ConcRefinementThreads` and `ConcGCThreads` are by default bounded by  ParallelGCThreads, but maybe we can use `G1ConcRefinementThreads` directly here.

+1 to not use `ParallelGCThreads`. I'd prefer using `ConcGCThreads` only.
`ConcGCThreads` is usually smaller than `ParallelGCThreads`, and concurrent refinement threads typically consume very little CPU compared to concurrent mark workers, and only a small subset of concurrent refinement threads are active. It seems better to ignore `G1ConcRefinementThreads`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2224621896

From tschatzl at openjdk.org  Wed Jul 23 09:29:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 23 Jul 2025 09:29:58 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v5]
In-Reply-To: <VnLSTr5JZTBzn1pkKeL1PP_8w6KS5aHeJEuXBbkmUBw=.2fb54f30-57ae-47be-adfb-2bf863219996@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <VnLSTr5JZTBzn1pkKeL1PP_8w6KS5aHeJEuXBbkmUBw=.2fb54f30-57ae-47be-adfb-2bf863219996@github.com>
Message-ID: <1LkE4_CtKtPJ3ar1We7P6DJNilCLzDOv_vff5YZVoXE=.453b1128-0df5-4960-8c98-7d9728eaf9b3@github.com>

On Fri, 18 Jul 2025 13:14:38 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - sgc-roots

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26038#pullrequestreview-3046494691

From ayang at openjdk.org  Wed Jul 23 13:31:57 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 23 Jul 2025 13:31:57 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v6]
In-Reply-To: <56Md8gVkunj4tfyMYyasTXVCYOTVfkXW5S7rTi9Khvs=.022a504d-67f5-413a-9c5b-e05d196b3285@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <56Md8gVkunj4tfyMYyasTXVCYOTVfkXW5S7rTi9Khvs=.022a504d-67f5-413a-9c5b-e05d196b3285@github.com>
Message-ID: <ucanFVYDSHaDQjU1olaQEJFTtQ21icNF1qRMA31jkKY=.20099618-5bd6-4c99-a55e-a3cc8441fb95@github.com>

On Tue, 22 Jul 2025 06:59:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * kbarret review, remove wb_breakpoint from possible cases where we can ignore the request if a concurrent mark is already running

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26189#pullrequestreview-3047466374

From tschatzl at openjdk.org  Wed Jul 23 13:43:04 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 23 Jul 2025 13:43:04 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v7]
In-Reply-To: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
Message-ID: <GdsPdeKhj8jvgN7DPfxuEK68gHrIFOPrrGVV3ehwKE4=.5c376c4d-756d-446e-87a7-33c29a1b76f4@github.com>

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

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

  * fix indentation of assert statement after Kim's request

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26189/files
  - new: https://git.openjdk.org/jdk/pull/26189/files/16aa539c..9c99cfce

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

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

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

From tschatzl at openjdk.org  Wed Jul 23 14:10:30 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 23 Jul 2025 14:10:30 GMT
Subject: RFR: 8363929: G1: Add G1 prefix to various G1 specific global locks
Message-ID: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>

Hi all,

  please review this renaming of a few G1 specific locks to have a G1 prefix to make it clear that they should not be used elsewhere.

Testing: local compilation, gha

Thanks,
  Thomas

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

Commit messages:
 - 8363929

Changes: https://git.openjdk.org/jdk/pull/26444/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363929
  Stats: 59 lines in 9 files changed: 6 ins; 6 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/26444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26444/head:pull/26444

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

From ayang at openjdk.org  Wed Jul 23 14:13:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 23 Jul 2025 14:13:55 GMT
Subject: RFR: 8363929: G1: Add G1 prefix to various G1 specific global
 locks
In-Reply-To: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
References: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
Message-ID: <fcqZRmXZ2SHobPuTrJpoeDiRocjFlVSPGJ1JZE79j8s=.aa9d36f1-2ae1-441e-b064-86d81ef42eb9@github.com>

On Wed, 23 Jul 2025 14:02:49 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this renaming of a few G1 specific locks to have a G1 prefix to make it clear that they should not be used elsewhere.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26444#pullrequestreview-3047645944

From tschatzl at openjdk.org  Wed Jul 23 14:34:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 23 Jul 2025 14:34:47 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v44]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <0KXHzGhrVDYfe_gWdT7DFsZYNyKDDVv9Os8K91HLfUQ=.b120a07e-95d0-4140-be81-a95e1b02f5d5@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 61 commits:

 - * remove unused G1DetachedRefinementStats_lock
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - 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
 - ... and 51 more: https://git.openjdk.org/jdk/compare/743c8212...dd836387

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=43
  Stats: 7122 lines in 112 files changed: 2588 ins; 3592 del; 942 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  Wed Jul 23 16:25:03 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 23 Jul 2025 16:25:03 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
Message-ID: <XoO60brvJtGWR8xGF7VYbC1qDWqOe_c2qnzTucAH-94=.b2926784-4790-417b-bde0-32a5c2aea1a7@github.com>

On Fri, 18 Jul 2025 13:13:38 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 33 commits:
> 
>  - merge
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - 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
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853

Looks good!

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

Marked as reviewed by zgu (Reviewer).

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

From kbarrett at openjdk.org  Wed Jul 23 16:32:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Jul 2025 16:32:11 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v7]
In-Reply-To: <GdsPdeKhj8jvgN7DPfxuEK68gHrIFOPrrGVV3ehwKE4=.5c376c4d-756d-446e-87a7-33c29a1b76f4@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <GdsPdeKhj8jvgN7DPfxuEK68gHrIFOPrrGVV3ehwKE4=.5c376c4d-756d-446e-87a7-33c29a1b76f4@github.com>
Message-ID: <yTd-vqi84K8LP51fOvCDjAGCqFjndhVTVMNJrIKzbc8=.2b8475fe-1188-4032-8ba1-66628c15408b@github.com>

On Wed, 23 Jul 2025 13:43:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
>> 
>> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
>> 
>> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
>> 
>> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
>> 
>> Testing: tier1-5, test case passing, failing before
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * fix indentation of assert statement after Kim's request

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26189#pullrequestreview-3048204796

From tschatzl at openjdk.org  Wed Jul 23 17:05:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 23 Jul 2025 17:05:03 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC [v7]
In-Reply-To: <yTd-vqi84K8LP51fOvCDjAGCqFjndhVTVMNJrIKzbc8=.2b8475fe-1188-4032-8ba1-66628c15408b@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
 <GdsPdeKhj8jvgN7DPfxuEK68gHrIFOPrrGVV3ehwKE4=.5c376c4d-756d-446e-87a7-33c29a1b76f4@github.com>
 <yTd-vqi84K8LP51fOvCDjAGCqFjndhVTVMNJrIKzbc8=.2b8475fe-1188-4032-8ba1-66628c15408b@github.com>
Message-ID: <Vrs5B2RcOG68AJnM-luRbhRHGFU1zOzLKL7hP-KHpA0=.87ef48f6-dd2c-46b6-812e-f7e60c5225dd@github.com>

On Wed, 23 Jul 2025 16:29:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * fix indentation of assert statement after Kim's request
>
> Looks good.

Thanks @kimbarrett @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26189#issuecomment-3109436201

From tschatzl at openjdk.org  Wed Jul 23 17:05:04 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 23 Jul 2025 17:05:04 GMT
Subject: Integrated: 8350621: Code cache stops scheduling GC
In-Reply-To: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
References: <vZ2CM0hIwnPQJFE5mXPCw9-yAtupxxW-3VqDCgi8XpQ=.ef4d6122-5ac9-47bd-9650-97c169894d10@github.com>
Message-ID: <prC82zqi1BaESQhy1YpenrwSlYEujc-FdPRpHsjqhlk=.e1ffcf7b-7a61-41ad-a7ff-c4b3d3b170b8@github.com>

On Tue, 8 Jul 2025 15:03:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 2292246f
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2292246f8c11f735f50e2046ec6606e89289e9f5
Stats:     391 lines in 8 files changed: 339 ins; 43 del; 9 mod

8350621: Code cache stops scheduling GC

Co-authored-by: Thomas Schatzl <tschatzl at openjdk.org>
Co-authored-by: Alexandre Jacob <alexandre.jacob at mirakl.com>
Reviewed-by: kbarrett, ayang

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

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

From dlong at openjdk.org  Wed Jul 23 19:55:34 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 23 Jul 2025 19:55:34 GMT
Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only
 MacOSX aarch64
Message-ID: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>

This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value.  Further, it takes a fast-path that uses the previous direct store when at a safepoint.  Combined, these changes should get us back to almost where we were before in terms of overhead.  If necessary, we could go even further and allow make_not_entrant() do a direct byte store, leaving 24 bits for the guard value.

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

Commit messages:
 - trailing white space
 - fix s390 copy-paste
 - use fast path for safepoints
 - ppc align check
 - ppc align
 - simplify x86
 - In CAS loop, update old_value from result of CAS
 - fix ppc build
 - fix zero build
 - ppc typos
 - ... and 3 more: https://git.openjdk.org/jdk/compare/cf75f1f9...ecc6e68e

Changes: https://git.openjdk.org/jdk/pull/26399/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361376
  Stats: 214 lines in 13 files changed: 118 ins; 58 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/26399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26399/head:pull/26399

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

From ayang at openjdk.org  Wed Jul 23 20:13:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 23 Jul 2025 20:13:13 GMT
Subject: Integrated: 8338977: Parallel: Improve heap resizing heuristics
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <VU9Tm1PI8Yz_DKDB9AtUQ2x2Y8DdEa4GwIi0GNPYH5o=.d7783ebb-8868-494c-a949-6bd827e316bc@github.com>

On Fri, 2 May 2025 10:23:25 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

This pull request has now been integrated.

Changeset: ad510fb2
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad510fb25e47098d136515c355164e5177c5b419
Stats:     4362 lines in 31 files changed: 507 ins; 3470 del; 385 mod

8338977: Parallel: Improve heap resizing heuristics

Reviewed-by: zgu, gli, iwalulya

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

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

From ayang at openjdk.org  Wed Jul 23 20:13:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 23 Jul 2025 20:13:12 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
Message-ID: <_Yg88tIFDmL4WUGVb--Xy-hih_0NrVkmqWU5FfFha4Y=.9e385636-1779-4189-855b-a123cd2b0cd7@github.com>

On Fri, 18 Jul 2025 13:13:38 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 33 commits:
> 
>  - merge
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - 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
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25000#issuecomment-3109989114

From wkemper at openjdk.org  Wed Jul 23 20:51:54 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Jul 2025 20:51:54 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
In-Reply-To: <ERrHXU5sLCOODE76903yuq-93ZVeqaakDj0DA_uuS70=.a928b2ee-2c78-4f1b-8be1-896fbbebf38a@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
 <ERrHXU5sLCOODE76903yuq-93ZVeqaakDj0DA_uuS70=.a928b2ee-2c78-4f1b-8be1-896fbbebf38a@github.com>
Message-ID: <MckiwZrH2_H5FbjL7EZRTpeDnT-jRSJS_qCriAXQi74=.a736c388-4a9a-44e4-839f-de5bbcee9b8a@github.com>

On Wed, 23 Jul 2025 01:30:19 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah has `product only` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.
>
> src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.cpp line 112:
> 
>> 110:   st->print("Young: "); _young.print_on(st);
>> 111:   st->print("Old: "); _old.print_on(st);
>> 112:   st->print("Promotion: "); _promotion.print_on(st);
> 
> Nit: I might switch the order of Promote & Old.

That makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26222#discussion_r2226659898

From wkemper at openjdk.org  Wed Jul 23 21:10:30 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Jul 2025 21:10:30 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
 [v2]
In-Reply-To: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
Message-ID: <Q9C7YSDa2D0qb8x08GW2OWRijalODQk8xKJVnu8MO8Y=.9ddaa4aa-beb8-4dea-ae83-ebc5a4e3c134@github.com>

> Shenandoah has `not product` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.

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

 - Merge remote-tracking branch 'jdk/master' into categorize-evacuations
 - Add documentation, change ordering of categories when printed (review feedback)
 - Convert evac tracking back into non-product feature
 - Re-enable evac tracker, account for young/old/promotions

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

Changes: https://git.openjdk.org/jdk/pull/26222/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26222&range=01
  Stats: 155 lines in 9 files changed: 86 ins; 25 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/26222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26222/head:pull/26222

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

From wkemper at openjdk.org  Wed Jul 23 23:16:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Jul 2025 23:16:42 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
 [v3]
In-Reply-To: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
Message-ID: <XTchf8jQW5t20h93Fm3iEaBh1i3U17TjunHWXozrlrI=.fad0b072-76e1-4102-bcf6-252f603da9c7@github.com>

> Shenandoah has `not product` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.

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

  Fix merge error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26222/files
  - new: https://git.openjdk.org/jdk/pull/26222/files/e1f8c9b9..23a86e36

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

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

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

From ysr at openjdk.org  Thu Jul 24 02:31:54 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 24 Jul 2025 02:31:54 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
 [v3]
In-Reply-To: <XTchf8jQW5t20h93Fm3iEaBh1i3U17TjunHWXozrlrI=.fad0b072-76e1-4102-bcf6-252f603da9c7@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
 <XTchf8jQW5t20h93Fm3iEaBh1i3U17TjunHWXozrlrI=.fad0b072-76e1-4102-bcf6-252f603da9c7@github.com>
Message-ID: <LULgl4DvkgOeAht4gMT0yyd4i6_drgksydzHR8aOAoU=.1ef26096-37b4-4a3f-915f-84a91ce0d416@github.com>

On Wed, 23 Jul 2025 23:16:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah has `not product` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge error

src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.hpp line 106:

> 104:   void begin_evacuation(Thread* thread, size_t bytes, ShenandoahAffiliation from, ShenandoahAffiliation to);
> 105: 
> 106:   // Multiple threads may attempt to evacuate the same object, but only the succeeding thread will end the evacuation.

Instead of `only the succeeding thread will end the evacuation`, I might say: `the unique thread that is successful will end the evacuation`. (Alternatively, replace "succeeding" with "successful"; the word "succeeding" as an adjective can be ambiguous in this context.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26222#discussion_r2227175181

From shade at openjdk.org  Thu Jul 24 08:35:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 08:35:55 GMT
Subject: RFR: 8363929: G1: Add G1 prefix to various G1 specific global
 locks
In-Reply-To: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
References: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
Message-ID: <C1TlhRfP_kPHjzF-V6P9DZ7GQ40XSjjjGbUNx7KbA9o=.143da656-d744-4ca1-b238-9ba11921af88@github.com>

On Wed, 23 Jul 2025 14:02:49 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this renaming of a few G1 specific locks to have a G1 prefix to make it clear that they should not be used elsewhere.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Looks reasonable, just needs a few more cosmetics.

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

> 71: extern Mutex*   NonJavaThreadsList_lock;         // a lock on the NonJavaThreads list
> 72: extern Mutex*   NonJavaThreadsListSync_lock;     // a lock for NonJavaThreads list synchronization
> 73: extern Monitor* G1CGC_lock;                        // used for coordination between

In all hunks in this file: comment indenting. May even add "G1" to comments, where appropriate.

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

PR Review: https://git.openjdk.org/jdk/pull/26444#pullrequestreview-3050656256
PR Review Comment: https://git.openjdk.org/jdk/pull/26444#discussion_r2227836256

From tschatzl at openjdk.org  Thu Jul 24 09:48:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 24 Jul 2025 09:48:58 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
Message-ID: <Jl3NDY1cRCuV3MRX08XT502IQtcR-hKi2TFmjxJEYG0=.476fc8cc-e099-47f9-b2c3-55c72b869144@github.com>

On Wed, 23 Jul 2025 06:31:04 GMT, Man Cao <manc at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - cleanup after merge
>>  - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact
>>  - Merge branch 'NormalizeTiming' into ConcCPUImpact
>>  - Thomas suggestion
>>  - Thomas Review
>>  - reorder
>>  - concurrent gc impact
>>  - clean out
>>  - init
>
> src/hotspot/share/gc/g1/g1Policy.cpp line 678:
> 
>> 676:   double cur_gc_cpu_time_ms = _g1h->elapsed_gc_cpu_time() * MILLIUNITS;
>> 677: 
>> 678:   double concurrent_gc_cpu_time_ms = cur_gc_cpu_time_ms - prev_gc_cpu_pause_end_ms;
> 
> `CollectedHeap::elapsed_gc_cpu_time()` includes  `_vmthread_cpu_time` and `string_dedup_cpu_time`. Should we exclude VM threads and StringDedup threads' CPU time from `concurrent_gc_cpu_time_ms`? Otherwise non-GC activities could affect G1's heap sizing decisions.

VMThread cpu time only contains VM thread cpu time for GC VM operations; string deduplication is a GC/memory management activity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2228023769

From ayang at openjdk.org  Thu Jul 24 10:13:21 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 24 Jul 2025 10:13:21 GMT
Subject: RFR: 8364019: Add alignment precondition to Universe::reserve_heap
Message-ID: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>

Simple converting a redundant `align_up` to assert.

Test: tier1

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

Commit messages:
 - heap-align-precondition

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

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

From tschatzl at openjdk.org  Thu Jul 24 10:28:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 24 Jul 2025 10:28:54 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <Jl3NDY1cRCuV3MRX08XT502IQtcR-hKi2TFmjxJEYG0=.476fc8cc-e099-47f9-b2c3-55c72b869144@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <Jl3NDY1cRCuV3MRX08XT502IQtcR-hKi2TFmjxJEYG0=.476fc8cc-e099-47f9-b2c3-55c72b869144@github.com>
Message-ID: <ghu5Vei9ov6gyY1zxXU7EOXQwNAHMPR_WJzCUhurHko=.b6a9260c-f3e0-4522-ab08-ad7a906eacf8@github.com>

On Thu, 24 Jul 2025 09:46:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Policy.cpp line 678:
>> 
>>> 676:   double cur_gc_cpu_time_ms = _g1h->elapsed_gc_cpu_time() * MILLIUNITS;
>>> 677: 
>>> 678:   double concurrent_gc_cpu_time_ms = cur_gc_cpu_time_ms - prev_gc_cpu_pause_end_ms;
>> 
>> `CollectedHeap::elapsed_gc_cpu_time()` includes  `_vmthread_cpu_time` and `string_dedup_cpu_time`. Should we exclude VM threads and StringDedup threads' CPU time from `concurrent_gc_cpu_time_ms`? Otherwise non-GC activities could affect G1's heap sizing decisions.
>
> VMThread cpu time only contains VM thread cpu time for GC VM operations; string deduplication is a GC/memory management activity.

Another issue seems to be that since both `record_pause_start()` and `record_pause()` are called for all pauses. It seems that this implementation only considers the concurrent CPU usage between Remark/Cleanup and Young pauses as G1 currently only resizes at Young collections.

The bulk of concurrent work is from Young -> Remark and Remark -> Cleanup though. If e.g. all of the concurrent cycles occurs between two Young GCs, that whole concurrent cycle seems to be lost in the calculation (or at least parts of the concurrent CPU usage)?

Or am I missing something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2228117822

From tschatzl at openjdk.org  Thu Jul 24 10:44:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 24 Jul 2025 10:44:54 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
Message-ID: <8jgch5Jzg-s3OcZTStnhziDVj221C-md0zkDWbL_Xvc=.9e14372b-8515-4b7c-8a34-63bf8faac785@github.com>

On Wed, 23 Jul 2025 07:00:46 GMT, Man Cao <manc at openjdk.org> wrote:

> However, it could be challenging in some environments. E.g. a background controller process that periodically runs taskset to change CPU affinity mask for the Java process, leading to os::active_processor_count() returning variable values.

As bad as it sounds, this is already basically an unsupported use case. G1 heuristic will be screwed already (actually lots of ergonomics/predictions do not even very well support wildly changing values returned from ergonomic thread sizing, i.e. self-inflicted thread number changes).

Use the `ActiveProcessorCount` option with an average or so.

I do not think it is the purpose of this change to try to go to great lengths to start supporting this use case. We can consider it though, but it should not prevent progress imo.

> Another scenario is that the Java process runs in a CPU-constraint container, but for some reasons has to run with -XX:-UseContainerSupport. Then all of os::active_processor_count(), ConcGCThreads, ParallelGCThreads could be much higher than the max # of available CPU cores.

We can't do much about this (bad configuration), and is already problematic wrt even to initial thread sizing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2228151874

From tschatzl at openjdk.org  Thu Jul 24 10:49:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 24 Jul 2025 10:49:53 GMT
Subject: RFR: 8363929: G1: Add G1 prefix to various G1 specific global
 locks
In-Reply-To: <C1TlhRfP_kPHjzF-V6P9DZ7GQ40XSjjjGbUNx7KbA9o=.143da656-d744-4ca1-b238-9ba11921af88@github.com>
References: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
 <C1TlhRfP_kPHjzF-V6P9DZ7GQ40XSjjjGbUNx7KbA9o=.143da656-d744-4ca1-b238-9ba11921af88@github.com>
Message-ID: <8NVSHlCh5kBlVyWfp7PjuA_f3f4-_baOvHOVt306ykE=.d6bda51b-de95-4318-bdbf-86500ab72f6c@github.com>

On Thu, 24 Jul 2025 08:32:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this renaming of a few G1 specific locks to have a G1 prefix to make it clear that they should not be used elsewhere.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/runtime/mutexLocker.hpp line 73:
> 
>> 71: extern Mutex*   NonJavaThreadsList_lock;         // a lock on the NonJavaThreads list
>> 72: extern Mutex*   NonJavaThreadsListSync_lock;     // a lock for NonJavaThreads list synchronization
>> 73: extern Monitor* G1CGC_lock;                        // used for coordination between
> 
> In all hunks in this file: comment indenting. May even add "G1" to comments, where appropriate.

I remember fixing the indentation, maybe it got lost somewhere. Thanks for pointing this out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26444#discussion_r2228162737

From tschatzl at openjdk.org  Thu Jul 24 10:58:10 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 24 Jul 2025 10:58:10 GMT
Subject: RFR: 8363929: G1: Add G1 prefix to various G1 specific global
 locks [v2]
In-Reply-To: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
References: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
Message-ID: <_dP0RIkEqBPbdMT-DFgI48v8f7thpVA4Ktgk9EX07o0=.accf3d10-e6a6-4b19-8c33-360b546a0365@github.com>

> Hi all,
> 
>   please review this renaming of a few G1 specific locks to have a G1 prefix to make it clear that they should not be used elsewhere.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

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

  * shade review: fix mutex comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26444/files
  - new: https://git.openjdk.org/jdk/pull/26444/files/27c8ad42..0616b8e6

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

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

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

From shade at openjdk.org  Thu Jul 24 11:07:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 11:07:54 GMT
Subject: RFR: 8363929: G1: Add G1 prefix to various G1 specific global
 locks [v2]
In-Reply-To: <_dP0RIkEqBPbdMT-DFgI48v8f7thpVA4Ktgk9EX07o0=.accf3d10-e6a6-4b19-8c33-360b546a0365@github.com>
References: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
 <_dP0RIkEqBPbdMT-DFgI48v8f7thpVA4Ktgk9EX07o0=.accf3d10-e6a6-4b19-8c33-360b546a0365@github.com>
Message-ID: <ilwEpYERsK8SJ0OpEF7waXRuLy732SN-k8QYxIkR9d8=.e37fbbf0-ec78-478c-a72e-999616e2d509@github.com>

On Thu, 24 Jul 2025 10:58:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this renaming of a few G1 specific locks to have a G1 prefix to make it clear that they should not be used elsewhere.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * shade review: fix mutex comments

Looks fine!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26444#pullrequestreview-3051190007

From iwalulya at openjdk.org  Thu Jul 24 12:07:53 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 24 Jul 2025 12:07:53 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <ghu5Vei9ov6gyY1zxXU7EOXQwNAHMPR_WJzCUhurHko=.b6a9260c-f3e0-4522-ab08-ad7a906eacf8@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <Jl3NDY1cRCuV3MRX08XT502IQtcR-hKi2TFmjxJEYG0=.476fc8cc-e099-47f9-b2c3-55c72b869144@github.com>
 <ghu5Vei9ov6gyY1zxXU7EOXQwNAHMPR_WJzCUhurHko=.b6a9260c-f3e0-4522-ab08-ad7a906eacf8@github.com>
Message-ID: <ib9HzNBSe9HG_1feXoUmOvtZhrNQbG5uLxJF_2Tofjk=.e0a4e188-e2b3-42d3-95ff-c1c95c36f18f@github.com>

On Thu, 24 Jul 2025 10:26:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> VMThread cpu time only contains VM thread cpu time for GC VM operations; string deduplication is a GC/memory management activity.
>
> Another issue seems to be that since both `record_pause_start()` and `record_pause()` are called for all pauses. It seems that this implementation only considers the concurrent CPU usage between Remark/Cleanup and Young pauses as G1 currently only resizes at Young collections.
> 
> The bulk of concurrent work is from Young -> Remark and Remark -> Cleanup though. If e.g. all of the concurrent cycles occurs between two Young GCs, that whole concurrent cycle seems to be lost in the calculation (or at least parts of the concurrent CPU usage)?
> 
> Or am I missing something?

The assumption here is the `update_gc_pause_time_ratios` is called at the end of all GCs. The only issue I notice is that we don't call it in case of allocation_failures, which is problematic. But probably I don't understand the issue you are highlighting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2228325405

From tschatzl at openjdk.org  Thu Jul 24 15:29:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 24 Jul 2025 15:29:56 GMT
Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4
 only MacOSX aarch64
In-Reply-To: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
References: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
Message-ID: <9OGIoq7EaDQnBhnzMzX3sHGq99xQHthjkG4xbxvSDzc=.9d5ed8b8-62bf-4f4e-b0dc-3cfb3193afca@github.com>

On Sat, 19 Jul 2025 01:39:12 GMT, Dean Long <dlong at openjdk.org> wrote:

> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value.  Further, it takes a fast-path that uses the previous direct store when at a safepoint.  Combined, these changes should get us back to almost where we were before in terms of overhead.  If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value.

Afaics the `NMethodEntryBarrier_lock` declaration/definition can also be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3113913189

From duke at openjdk.org  Thu Jul 24 18:03:55 2025
From: duke at openjdk.org (Rui Li)
Date: Thu, 24 Jul 2025 18:03:55 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
Message-ID: <dpXLiElD-HG7M5TXg0YoU5ivMGjVn7DswGCxlFwSpSM=.fd4a2f28-b99f-45f3-828d-59c017540f52@github.com>

On Fri, 11 Jul 2025 18:24:56 GMT, Rui Li <duke at openjdk.org> wrote:

> Add logging for Shenandoah as well as Generational Shenandoah. 
> 
> Log samples:
> 
> 
> ######################################
> Before gc
> ######################################
> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.231s][debug][gc,heap      ] GC(0) 
> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> 
> 
> 
> ######################################
> After gc
> ######################################
> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
> [2.067s][debug][gc,heap        ] GC(11) 
> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

Thanks all. Opened another JBS to fix the missing `increment_total_collections` in Shenandoah / GenShen, as well as to improve the GenShen logging. 

Keep this PR as it is and continue integrating this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26272#issuecomment-3114359842

From duke at openjdk.org  Thu Jul 24 18:03:55 2025
From: duke at openjdk.org (duke)
Date: Thu, 24 Jul 2025 18:03:55 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
Message-ID: <bqPP8DekVXlqmBrW2Q6WiKE5uT7_6fZHW-uqRvu2zPM=.449cb670-6b06-4f07-bab7-08d9ee85f3a9@github.com>

On Fri, 11 Jul 2025 18:24:56 GMT, Rui Li <duke at openjdk.org> wrote:

> Add logging for Shenandoah as well as Generational Shenandoah. 
> 
> Log samples:
> 
> 
> ######################################
> Before gc
> ######################################
> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.231s][debug][gc,heap      ] GC(0) 
> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> 
> 
> 
> ######################################
> After gc
> ######################################
> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
> [2.067s][debug][gc,heap        ] GC(11) 
> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26272#issuecomment-3114364491

From wkemper at openjdk.org  Thu Jul 24 18:38:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 24 Jul 2025 18:38:13 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
 [v4]
In-Reply-To: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
Message-ID: <W5MgjOjLy5STjulDf1_WRIHTYgylFb4DhYS90uNttTE=.09cd4a49-1894-4a49-9800-f9cbcc69de5c@github.com>

> Shenandoah has `not product` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.

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

  Change wording in commment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26222/files
  - new: https://git.openjdk.org/jdk/pull/26222/files/23a86e36..cd69cd92

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

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

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

From duke at openjdk.org  Thu Jul 24 18:36:59 2025
From: duke at openjdk.org (Rui Li)
Date: Thu, 24 Jul 2025 18:36:59 GMT
Subject: Integrated: 8357818: Shenandoah doesn't use shared API for printing
 heap before/after GC
In-Reply-To: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
Message-ID: <hXptfocWhJGI-5P-J53FgUrKwAu9v8ZQyVmieTUD1IM=.77a8a6c9-fd77-44c4-9770-1f839b341b93@github.com>

On Fri, 11 Jul 2025 18:24:56 GMT, Rui Li <duke at openjdk.org> wrote:

> Add logging for Shenandoah as well as Generational Shenandoah. 
> 
> Log samples:
> 
> 
> ######################################
> Before gc
> ######################################
> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.231s][debug][gc,heap      ] GC(0) 
> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> 
> 
> 
> ######################################
> After gc
> ######################################
> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
> [2.067s][debug][gc,heap        ] GC(11) 
> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

This pull request has now been integrated.

Changeset: 4e53a9d9
Author:    Rui Li <ruiamzn at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e53a9d9dfe7a1ac7c3d7402e5ca3a3d3fcbb709
Stats:     4 lines in 2 files changed: 4 ins; 0 del; 0 mod

8357818: Shenandoah doesn't use shared API for printing heap before/after GC

Reviewed-by: wkemper, kdnilsen

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

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

From dlong at openjdk.org  Thu Jul 24 18:51:22 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 24 Jul 2025 18:51:22 GMT
Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4
 only MacOSX aarch64 [v2]
In-Reply-To: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
References: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
Message-ID: <pGV8Db8JQIT-K6I0GWaRe9n9GsAlHKjwkAfV7kw2Lmo=.df3e4a96-cc73-4a84-98c3-b044cbd2d3a4@github.com>

> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value.  Further, it takes a fast-path that uses the previous direct store when at a safepoint.  Combined, these changes should get us back to almost where we were before in terms of overhead.  If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value.

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

  remove NMethodEntryBarrier_lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26399/files
  - new: https://git.openjdk.org/jdk/pull/26399/files/ecc6e68e..e05605eb

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

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

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

From manc at openjdk.org  Thu Jul 24 21:00:53 2025
From: manc at openjdk.org (Man Cao)
Date: Thu, 24 Jul 2025 21:00:53 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <8jgch5Jzg-s3OcZTStnhziDVj221C-md0zkDWbL_Xvc=.9e14372b-8515-4b7c-8a34-63bf8faac785@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <8jgch5Jzg-s3OcZTStnhziDVj221C-md0zkDWbL_Xvc=.9e14372b-8515-4b7c-8a34-63bf8faac785@github.com>
Message-ID: <gJkv-psQP-b4y4JBqid9sc1EbbgbD7xqrvJbmnjLilA=.7871f970-439a-4a62-999e-38389ab49ebc@github.com>

On Thu, 24 Jul 2025 10:42:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Analytics.cpp line 173:
>> 
>>> 171:   // activity. We do not account for contention on other shared resources such as memory bandwidth and
>>> 172:   // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
>>> 173:   uint num_cpus = (uint)os::active_processor_count();
>> 
>> It is a good idea to convert CPU time to wall-clock time "lost" by mutator threads. However, it could be challenging in some environments. E.g. a background controller process that periodically runs `taskset` to change CPU affinity mask for the Java process, leading to `os::active_processor_count()` returning variable values.
>> Another scenario is that the Java process runs in a CPU-constraint container, but for some reasons has to run with `-XX:-UseContainerSupport`. Then all of `os::active_processor_count()`, `ConcGCThreads`, `ParallelGCThreads` could be much higher than the max # of available CPU cores.
>> 
>> Our internal infra has both issues above, and I don't have a good idea to mitigate them in G1. I think the current approach is acceptable: due to the latter `-XX:-UseContainerSupport` issue, it will mostly lead to under-counting concurrent GC CPU time, which is not a show stopper.
>
>> However, it could be challenging in some environments. E.g. a background controller process that periodically runs taskset to change CPU affinity mask for the Java process, leading to os::active_processor_count() returning variable values.
> 
> As bad as it sounds, this is already basically an unsupported use case. G1 heuristic will be screwed already (actually lots of ergonomics/predictions do not even very well support wildly changing values returned from ergonomic thread sizing, i.e. self-inflicted thread number changes).
> 
> Use the `ActiveProcessorCount` option with an average or so.
> 
> I do not think it is the purpose of this change to try to go to great lengths to start supporting this use case. We can consider it though, but it should not prevent progress imo.
> 
>> Another scenario is that the Java process runs in a CPU-constraint container, but for some reasons has to run with -XX:-UseContainerSupport. Then all of os::active_processor_count(), ConcGCThreads, ParallelGCThreads could be much higher than the max # of available CPU cores.
> 
> We can't do much about this (bad configuration), and is already problematic wrt even to initial thread sizing.

Ack on both points. There is no need to address these issues for this PR. Our infra is basically "too dynamic" that could mess up many heuristics in the JVM. Also agree that `ActiveProcessorCount` is a reasonable workaround in such dynamic infra.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2229561943

From wkemper at openjdk.org  Thu Jul 24 23:48:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 24 Jul 2025 23:48:00 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
 [v4]
In-Reply-To: <W5MgjOjLy5STjulDf1_WRIHTYgylFb4DhYS90uNttTE=.09cd4a49-1894-4a49-9800-f9cbcc69de5c@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
 <W5MgjOjLy5STjulDf1_WRIHTYgylFb4DhYS90uNttTE=.09cd4a49-1894-4a49-9800-f9cbcc69de5c@github.com>
Message-ID: <GPL3nKJECB-S3pgrZQE-XhL7ZnAMq-1hNHxLL5TOpo8=.334b599d-0682-4d01-b6fd-f58b77b2c37b@github.com>

On Thu, 24 Jul 2025 18:38:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah has `not product` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change wording in commment

GHA failure on macos looks unrelated (test was running G1).

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

PR Comment: https://git.openjdk.org/jdk/pull/26222#issuecomment-3115342198

From ayang at openjdk.org  Fri Jul 25 09:53:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 25 Jul 2025 09:53:10 GMT
Subject: RFR: 8364110: Remove unused methods in GCCause
Message-ID: <3MwnkqwlgZBZQ5l33RLJYyhevqEhQnR-TvwFEUvSWJw=.9f264ce8-68a1-4a27-82b7-681a14c2de54@github.com>

Trivial removing dead code.

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

Commit messages:
 - gc-cause-trivial-remove

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

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

From kbarrett at openjdk.org  Fri Jul 25 10:08:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 25 Jul 2025 10:08:53 GMT
Subject: RFR: 8364110: Remove unused methods in GCCause
In-Reply-To: <3MwnkqwlgZBZQ5l33RLJYyhevqEhQnR-TvwFEUvSWJw=.9f264ce8-68a1-4a27-82b7-681a14c2de54@github.com>
References: <3MwnkqwlgZBZQ5l33RLJYyhevqEhQnR-TvwFEUvSWJw=.9f264ce8-68a1-4a27-82b7-681a14c2de54@github.com>
Message-ID: <CZvqohgpnt-vH-hbGpa-Sw_2d7oxUVtRdzfZjt74-n8=.2150b76a-1180-47ff-a0d2-1c25d7d5170a@github.com>

On Fri, 25 Jul 2025 09:48:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Looks good, and trivial.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26476#pullrequestreview-3054854392

From mbaesken at openjdk.org  Fri Jul 25 12:12:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 25 Jul 2025 12:12:01 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue
In-Reply-To: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
Message-ID: <oRiSibm7KnpdIs1EweP2tk1jWykmDaU2RRrGvH77C2w=.adc359ae-9c5c-491e-987a-e7d70539c48e@github.com>

On Tue, 8 Jul 2025 13:31:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test
> gc/z/TestMappedCacheHarvest.java
> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
> 
> 
>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
> young_to_old_ratio:27561965412.478878
> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
> `uint(young_workers * young_to_old_ratio)` .
> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

Hi ZGC team, any comments ? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26186#issuecomment-3117547942

From duke at openjdk.org  Fri Jul 25 14:12:05 2025
From: duke at openjdk.org (Rui Li)
Date: Fri, 25 Jul 2025 14:12:05 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement
Message-ID: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>

Fix missing `increment_total_collections` usages in Shenandoah (otherwise, the invocation count is always 0 as shown in https://github.com/openjdk/jdk/pull/26272 overview). 

Also added some generational information for generational shenandoah logging.

Shenandoah logging samples:


######################
Shenandoah - Beore GC
######################
[0.161s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
[0.161s][debug][gc,heap      ] GC(0)  Shenandoah Heap
[0.161s][debug][gc,heap      ] GC(0)    100M max, 100M soft max, 100M committed, 40312K used
[0.161s][debug][gc,heap      ] GC(0)   400 x 256K regions
[0.161s][debug][gc,heap      ] GC(0)  Status: not cancelled
[0.161s][debug][gc,heap      ] GC(0)  Reserved region:
[0.161s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
[0.161s][debug][gc,heap      ] GC(0)  Collection set:
[0.161s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
[0.161s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
[0.161s][debug][gc,heap      ] GC(0) 
[0.161s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
[0.161s][debug][gc,metaspace ] GC(0)  Metaspace       used 86K, committed 320K, reserved 1114112K
[0.161s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K

######################
Shenandoah - After GC
######################
[2.179s][debug][gc,heap        ] GC(9) Heap After GC invocations=17 (full 7):
[2.179s][debug][gc,heap        ] GC(9)  Shenandoah Heap
[2.179s][debug][gc,heap        ] GC(9)    100M max, 100M soft max, 100M committed, 97113K used
[2.179s][debug][gc,heap        ] GC(9)   400 x 256K regions
[2.179s][debug][gc,heap        ] GC(9)  Status: not cancelled
[2.179s][debug][gc,heap        ] GC(9)  Reserved region:
[2.179s][debug][gc,heap        ] GC(9)   - [0x00000000f9c00000, 0x0000000100000000) 
[2.179s][debug][gc,heap        ] GC(9)  Collection set:
[2.179s][debug][gc,heap        ] GC(9)   - map (vanilla): 0x0000000000004e70
[2.179s][debug][gc,heap        ] GC(9)   - map (biased):  0x0000000000001000
[2.179s][debug][gc,heap        ] GC(9) 
[2.179s][debug][gc,metaspace   ] GC(9) Metaspace After GC invocations=17 (full 7):
[2.179s][debug][gc,metaspace   ] GC(9)  Metaspace       used 125K, committed 320K, reserved 1114112K
[2.179s][debug][gc,metaspace   ] GC(9)   class space    used 4K, committed 128K, reserved 1048576K


Generational Shenandoah logging samples

######################
Generational Shenandoah - Beore GC
######################
[0.212s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
[0.212s][debug][gc,heap      ] GC(0)  Generational Shenandoah Heap
[0.212s][debug][gc,heap      ] GC(0)   Young:
[0.212s][debug][gc,heap      ] GC(0)    100M max, 39686K used
[0.212s][debug][gc,heap      ] GC(0)   Old:
[0.212s][debug][gc,heap      ] GC(0)    0B max, 0B used
[0.212s][debug][gc,heap      ] GC(0)   Entire heap:
[0.212s][debug][gc,heap      ] GC(0)    100M soft max, 100M committed
[0.212s][debug][gc,heap      ] GC(0)  Status: not cancelled
[0.212s][debug][gc,heap      ] GC(0)  Reserved region:
[0.212s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
[0.212s][debug][gc,heap      ] GC(0)  Collection set:
[0.212s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
[0.212s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
[0.212s][debug][gc,heap      ] GC(0) 
[0.212s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
[0.212s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
[0.212s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K

######################
Generational Shenandoah - After GC
######################
[1.752s][debug][gc,heap        ] GC(18) Heap After GC invocations=19 (full 3):
[1.752s][debug][gc,heap        ] GC(18)  Generational Shenandoah Heap
[1.752s][debug][gc,heap        ] GC(18)   Young:
[1.752s][debug][gc,heap        ] GC(18)    3328K max, 2883K used
[1.752s][debug][gc,heap        ] GC(18)   Old:
[1.752s][debug][gc,heap        ] GC(18)    99072K max, 98060K used
[1.752s][debug][gc,heap        ] GC(18)   Entire heap:
[1.752s][debug][gc,heap        ] GC(18)    100M soft max, 100M committed
[1.752s][debug][gc,heap        ] GC(18)  Status: young marking, cancelled
[1.752s][debug][gc,heap        ] GC(18)  Reserved region:
[1.752s][debug][gc,heap        ] GC(18)   - [0x00000000f9c00000, 0x0000000100000000) 
[1.752s][debug][gc,heap        ] GC(18)  Collection set:
[1.752s][debug][gc,heap        ] GC(18)   - map (vanilla): 0x0000000000004e70
[1.752s][debug][gc,heap        ] GC(18)   - map (biased):  0x0000000000001000
[1.752s][debug][gc,heap        ] GC(18) 
[1.752s][debug][gc,metaspace   ] GC(18) Metaspace After GC invocations=19 (full 3):
[1.752s][debug][gc,metaspace   ] GC(18)  Metaspace       used 209K, committed 448K, reserved 1114112K
[1.752s][debug][gc,metaspace   ] GC(18)   class space    used 7K, committed 128K, reserved 1048576K

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

Commit messages:
 - 8364081: Shenandoah & GenShen logging improvement

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

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

From ayang at openjdk.org  Fri Jul 25 14:55:59 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 25 Jul 2025 14:55:59 GMT
Subject: RFR: 8364110: Remove unused methods in GCCause
In-Reply-To: <3MwnkqwlgZBZQ5l33RLJYyhevqEhQnR-TvwFEUvSWJw=.9f264ce8-68a1-4a27-82b7-681a14c2de54@github.com>
References: <3MwnkqwlgZBZQ5l33RLJYyhevqEhQnR-TvwFEUvSWJw=.9f264ce8-68a1-4a27-82b7-681a14c2de54@github.com>
Message-ID: <sElNebr3I1yDjoeGmRHHRHmV5pPkLoUf8XI0ES7ULjE=.bd27c39f-e88d-4094-a799-07784e81252f@github.com>

On Fri, 25 Jul 2025 09:48:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26476#issuecomment-3118282537

From ayang at openjdk.org  Fri Jul 25 14:56:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 25 Jul 2025 14:56:00 GMT
Subject: Integrated: 8364110: Remove unused methods in GCCause
In-Reply-To: <3MwnkqwlgZBZQ5l33RLJYyhevqEhQnR-TvwFEUvSWJw=.9f264ce8-68a1-4a27-82b7-681a14c2de54@github.com>
References: <3MwnkqwlgZBZQ5l33RLJYyhevqEhQnR-TvwFEUvSWJw=.9f264ce8-68a1-4a27-82b7-681a14c2de54@github.com>
Message-ID: <CHm5FwR00NbHEKilAG1BkA5zzTv3T-na4ZRydD3nnEk=.e2656d49-0591-4968-a4af-6b09c35aad31@github.com>

On Fri, 25 Jul 2025 09:48:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

This pull request has now been integrated.

Changeset: 9e209fef
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e209fef86fe75fb09734c9112fd1d8490c22413
Stats:     20 lines in 1 file changed: 0 ins; 20 del; 0 mod

8364110: Remove unused methods in GCCause

Reviewed-by: kbarrett

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

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

From duke at openjdk.org  Fri Jul 25 15:55:10 2025
From: duke at openjdk.org (Rui Li)
Date: Fri, 25 Jul 2025 15:55:10 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v2]
In-Reply-To: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
Message-ID: <fAGEZNI-5QjutT5CW-5P4jylB7-UjrrTNocL9zgtckc=.c51c903e-606c-4a09-82a7-41220c65bd5e@github.com>

> Fix missing `increment_total_collections` usages in Shenandoah (otherwise, the invocation count is always 0 as shown in https://github.com/openjdk/jdk/pull/26272 overview). 
> 
> Also added some generational information for generational shenandoah logging.
> 
> Shenandoah logging samples:
> 
> 
> ######################
> Shenandoah - Beore GC
> ######################
> [0.161s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.161s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.161s][debug][gc,heap      ] GC(0)    100M max, 100M soft max, 100M committed, 40312K used
> [0.161s][debug][gc,heap      ] GC(0)   400 x 256K regions
> [0.161s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.161s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.161s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.161s][debug][gc,heap      ] GC(0)  Collection set:
> [0.161s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.161s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.161s][debug][gc,heap      ] GC(0) 
> [0.161s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.161s][debug][gc,metaspace ] GC(0)  Metaspace       used 86K, committed 320K, reserved 1114112K
> [0.161s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> ######################
> Shenandoah - After GC
> ######################
> [2.179s][debug][gc,heap        ] GC(9) Heap After GC invocations=17 (full 7):
> [2.179s][debug][gc,heap        ] GC(9)  Shenandoah Heap
> [2.179s][debug][gc,heap        ] GC(9)    100M max, 100M soft max, 100M committed, 97113K used
> [2.179s][debug][gc,heap        ] GC(9)   400 x 256K regions
> [2.179s][debug][gc,heap        ] GC(9)  Status: not cancelled
> [2.179s][debug][gc,heap        ] GC(9)  Reserved region:
> [2.179s][debug][gc,heap        ] GC(9)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.179s][debug][gc,heap        ] GC(9)  Collection set:
> [2.179s][debug][gc,heap        ] GC(9)   - map (vanilla): 0x0000000000004e70
> [2.179s][debug][gc,heap        ] GC(9)   - map (biased):  0x0000000000001000
> [2.179s][debug][gc,heap        ] GC(9) 
> [2.179s][debug][gc,metaspace   ] GC(9) Metaspace After GC invocations=17 (full 7):
> [2.179s][debug][gc,metaspace   ] GC(9)  Metaspace       used 125K, committed 320K, reserved 1114112K
> [2.179s][debug][gc,metaspace   ] GC(9)   class space    used 4K, committed 128K, reserved 1048576K
> 
> 
> Generational Shenandoah logging samples
> 
> #############...

Rui Li has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8364081: Shenandoah & GenShen logging improvement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26469/files
  - new: https://git.openjdk.org/jdk/pull/26469/files/235aac2f..1d51fcff

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

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

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

From ysr at openjdk.org  Fri Jul 25 17:48:55 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 25 Jul 2025 17:48:55 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
 [v4]
In-Reply-To: <W5MgjOjLy5STjulDf1_WRIHTYgylFb4DhYS90uNttTE=.09cd4a49-1894-4a49-9800-f9cbcc69de5c@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
 <W5MgjOjLy5STjulDf1_WRIHTYgylFb4DhYS90uNttTE=.09cd4a49-1894-4a49-9800-f9cbcc69de5c@github.com>
Message-ID: <q0m7i4BNfSr5yEQsBKDuTIyps-OVncZ7gsWtRr_n4Lw=.88f601ff-002f-40b6-9580-2571da726c58@github.com>

On Thu, 24 Jul 2025 18:38:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah has `not product` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change wording in commment

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26222#pullrequestreview-3056328088

From wkemper at openjdk.org  Fri Jul 25 18:03:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 25 Jul 2025 18:03:01 GMT
Subject: Integrated: 8361726: Shenandoah: More detailed evacuation
 instrumentation
In-Reply-To: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
References: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>
Message-ID: <5ahQ7oNDhaod9xIYgMMZ694x3bpXqu4gQcc8yh8utnk=.bc882e19-3a17-4b65-8e40-53d80cd85bf5@github.com>

On Wed, 9 Jul 2025 17:52:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah has `not product` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.

This pull request has now been integrated.

Changeset: e756c0db
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e756c0dbbb7d99df0751d71726b173e4eabcc903
Stats:     156 lines in 9 files changed: 86 ins; 26 del; 44 mod

8361726: Shenandoah: More detailed evacuation instrumentation

Reviewed-by: ysr, kdnilsen

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

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

From wkemper at openjdk.org  Fri Jul 25 21:13:54 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 25 Jul 2025 21:13:54 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v2]
In-Reply-To: <fAGEZNI-5QjutT5CW-5P4jylB7-UjrrTNocL9zgtckc=.c51c903e-606c-4a09-82a7-41220c65bd5e@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
 <fAGEZNI-5QjutT5CW-5P4jylB7-UjrrTNocL9zgtckc=.c51c903e-606c-4a09-82a7-41220c65bd5e@github.com>
Message-ID: <tHSKe_N-joW6gJUxzaF0ts_5jPSDX3CMQXmiSSt-HUQ=.e17f1441-97aa-4641-be5e-305048a7eebe@github.com>

On Fri, 25 Jul 2025 15:55:10 GMT, Rui Li <duke at openjdk.org> wrote:

>> Fix missing `increment_total_collections` usages in Shenandoah (otherwise, the invocation count is always 0 as shown in https://github.com/openjdk/jdk/pull/26272 overview). 
>> 
>> Also added some generational information for generational shenandoah logging.
>> 
>> Shenandoah logging samples:
>> 
>> 
>> ######################
>> Shenandoah - Beore GC
>> ######################
>> [0.161s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,heap      ] GC(0)  Shenandoah Heap
>> [0.161s][debug][gc,heap      ] GC(0)    100M max, 100M soft max, 100M committed, 40312K used
>> [0.161s][debug][gc,heap      ] GC(0)   400 x 256K regions
>> [0.161s][debug][gc,heap      ] GC(0)  Status: not cancelled
>> [0.161s][debug][gc,heap      ] GC(0)  Reserved region:
>> [0.161s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [0.161s][debug][gc,heap      ] GC(0)  Collection set:
>> [0.161s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
>> [0.161s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
>> [0.161s][debug][gc,heap      ] GC(0) 
>> [0.161s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,metaspace ] GC(0)  Metaspace       used 86K, committed 320K, reserved 1114112K
>> [0.161s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
>> 
>> ######################
>> Shenandoah - After GC
>> ######################
>> [2.179s][debug][gc,heap        ] GC(9) Heap After GC invocations=17 (full 7):
>> [2.179s][debug][gc,heap        ] GC(9)  Shenandoah Heap
>> [2.179s][debug][gc,heap        ] GC(9)    100M max, 100M soft max, 100M committed, 97113K used
>> [2.179s][debug][gc,heap        ] GC(9)   400 x 256K regions
>> [2.179s][debug][gc,heap        ] GC(9)  Status: not cancelled
>> [2.179s][debug][gc,heap        ] GC(9)  Reserved region:
>> [2.179s][debug][gc,heap        ] GC(9)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [2.179s][debug][gc,heap        ] GC(9)  Collection set:
>> [2.179s][debug][gc,heap        ] GC(9)   - map (vanilla): 0x0000000000004e70
>> [2.179s][debug][gc,heap        ] GC(9)   - map (biased):  0x0000000000001000
>> [2.179s][debug][gc,heap        ] GC(9) 
>> [2.179s][debug][gc,metaspace   ] GC(9) Metaspace After GC invocations=17 (full 7):
>> [2.179s][debug][gc,metaspace   ] GC(9)  Metaspace       used 125K, committed 320K, reserved 1114112K
>> [2.179s][debug][gc,metaspace   ] GC(9)   class space    used 4K, commit...
>
> Rui Li has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8364081: Shenandoah & GenShen logging improvement

LGTM. Thanks for fixing this.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26469#pullrequestreview-3056801395

From ysr at openjdk.org  Fri Jul 25 21:59:59 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 25 Jul 2025 21:59:59 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v2]
In-Reply-To: <fAGEZNI-5QjutT5CW-5P4jylB7-UjrrTNocL9zgtckc=.c51c903e-606c-4a09-82a7-41220c65bd5e@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
 <fAGEZNI-5QjutT5CW-5P4jylB7-UjrrTNocL9zgtckc=.c51c903e-606c-4a09-82a7-41220c65bd5e@github.com>
Message-ID: <_Zy6ZBdYt_pCQQKo0i_l5LCMHuvScalqFepGE3Am4Bo=.a511d094-23ad-44f4-a6ab-3775885cd6f7@github.com>

On Fri, 25 Jul 2025 15:55:10 GMT, Rui Li <duke at openjdk.org> wrote:

>> Fix missing `increment_total_collections` usages in Shenandoah (otherwise, the invocation count is always 0 as shown in https://github.com/openjdk/jdk/pull/26272 overview). 
>> 
>> Also added some generational information for generational shenandoah logging.
>> 
>> Shenandoah logging samples:
>> 
>> 
>> ######################
>> Shenandoah - Beore GC
>> ######################
>> [0.161s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,heap      ] GC(0)  Shenandoah Heap
>> [0.161s][debug][gc,heap      ] GC(0)    100M max, 100M soft max, 100M committed, 40312K used
>> [0.161s][debug][gc,heap      ] GC(0)   400 x 256K regions
>> [0.161s][debug][gc,heap      ] GC(0)  Status: not cancelled
>> [0.161s][debug][gc,heap      ] GC(0)  Reserved region:
>> [0.161s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [0.161s][debug][gc,heap      ] GC(0)  Collection set:
>> [0.161s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
>> [0.161s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
>> [0.161s][debug][gc,heap      ] GC(0) 
>> [0.161s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,metaspace ] GC(0)  Metaspace       used 86K, committed 320K, reserved 1114112K
>> [0.161s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
>> 
>> ######################
>> Shenandoah - After GC
>> ######################
>> [2.179s][debug][gc,heap        ] GC(9) Heap After GC invocations=17 (full 7):
>> [2.179s][debug][gc,heap        ] GC(9)  Shenandoah Heap
>> [2.179s][debug][gc,heap        ] GC(9)    100M max, 100M soft max, 100M committed, 97113K used
>> [2.179s][debug][gc,heap        ] GC(9)   400 x 256K regions
>> [2.179s][debug][gc,heap        ] GC(9)  Status: not cancelled
>> [2.179s][debug][gc,heap        ] GC(9)  Reserved region:
>> [2.179s][debug][gc,heap        ] GC(9)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [2.179s][debug][gc,heap        ] GC(9)  Collection set:
>> [2.179s][debug][gc,heap        ] GC(9)   - map (vanilla): 0x0000000000004e70
>> [2.179s][debug][gc,heap        ] GC(9)   - map (biased):  0x0000000000001000
>> [2.179s][debug][gc,heap        ] GC(9) 
>> [2.179s][debug][gc,metaspace   ] GC(9) Metaspace After GC invocations=17 (full 7):
>> [2.179s][debug][gc,metaspace   ] GC(9)  Metaspace       used 125K, committed 320K, reserved 1114112K
>> [2.179s][debug][gc,metaspace   ] GC(9)   class space    used 4K, commit...
>
> Rui Li has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8364081: Shenandoah & GenShen logging improvement

I am wondering if we could just hoist the incrementing of the collections count to `run_gc_cycle()` which would normally take care of everything at once in one place, with the option `true` for stw and full cases.

It would probably miss the upgrade to full at a degen. We could either overcount by incrementing at the point of upgrade to full or gloss over it. I'd do the former (which is what I believe your degen upgrade to full does here).

(The other, perhaps arguably (or subjectively) better semantics, for full in the case of concurrent collectors is to conflate degens with full, treating both as a kind of failure of concurrent mode.

The problem is that the "total collections & full collections" terminology is inadequate when we have concurrent gcs, both young & old, global (explicit system.gc() invoking a concurrent gobal), and concurrent mode failures (degens) of each kind of collection. So I am guessing at some point we'll need to expand this semantics smoothly to accommodate these other kinds of collection.

However, this can be done later as an RFE that smoothly integrates what JFR et al. do as well.)

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 582:

> 580: 
> 581: void ShenandoahHeap::print_heap_on(outputStream* st) const {
> 582:   bool is_generational = mode()->is_generational();

`const`

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 602:

> 600:     st->print_cr(" %zu x " PROPERFMT " regions",
> 601:                 num_regions(),
> 602:                 PROPERFMTARGS(ShenandoahHeapRegion::region_size_bytes()));

I'd print this info for GenShen above as well.

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

PR Review: https://git.openjdk.org/jdk/pull/26469#pullrequestreview-3056812581
PR Review Comment: https://git.openjdk.org/jdk/pull/26469#discussion_r2232023228
PR Review Comment: https://git.openjdk.org/jdk/pull/26469#discussion_r2232053574

From kbarrett at openjdk.org  Fri Jul 25 22:08:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 25 Jul 2025 22:08:56 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v5]
In-Reply-To: <VnLSTr5JZTBzn1pkKeL1PP_8w6KS5aHeJEuXBbkmUBw=.2fb54f30-57ae-47be-adfb-2bf863219996@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <VnLSTr5JZTBzn1pkKeL1PP_8w6KS5aHeJEuXBbkmUBw=.2fb54f30-57ae-47be-adfb-2bf863219996@github.com>
Message-ID: <laXXA1EUwLKdzbUMg8PQmnMkibqJJQD-hQ70GrBUu2I=.971bd473-1be6-4e39-964d-94b81b9fdf27@github.com>

On Fri, 18 Jul 2025 13:14:38 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - sgc-roots

I'm still not entirely convinced that spreading things out is an improvement.
I think I would have preferred improvements to the centralized approach.
But this is better than what we currently have.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26038#pullrequestreview-3056891044

From dlong at openjdk.org  Sat Jul 26 01:40:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Jul 2025 01:40:08 GMT
Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4
 only MacOSX aarch64 [v2]
In-Reply-To: <pGV8Db8JQIT-K6I0GWaRe9n9GsAlHKjwkAfV7kw2Lmo=.df3e4a96-cc73-4a84-98c3-b044cbd2d3a4@github.com>
References: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
 <pGV8Db8JQIT-K6I0GWaRe9n9GsAlHKjwkAfV7kw2Lmo=.df3e4a96-cc73-4a84-98c3-b044cbd2d3a4@github.com>
Message-ID: <FEzUdgFuEI3sZbOTMmri1b0cOfifT38jmdnDgpIWN-U=.ac4caa4c-f352-4b95-9a7e-57f201c1e6ce@github.com>

On Thu, 24 Jul 2025 18:51:22 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value.  Further, it takes a fast-path that uses the previous direct store when at a safepoint.  Combined, these changes should get us back to almost where we were before in terms of overhead.  If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove NMethodEntryBarrier_lock

Unfortunately, I am still seeing a small 1% regression in Renaissance-NaiveBayes with ZGC.

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

PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3120938875

From duke at openjdk.org  Sat Jul 26 09:58:06 2025
From: duke at openjdk.org (duke)
Date: Sat, 26 Jul 2025 09:58:06 GMT
Subject: Withdrawn: 8357471: GenShen: Share collector reserves between young
 and old
In-Reply-To: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
Message-ID: <Z5zKAYSfgN9Noa15xJXDG8lQVxD91iCGNxm56tWE7yw=.51259036-9282-4e20-9208-46bcdb918ca8@github.com>

On Wed, 21 May 2025 15:29:09 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Genshen independently reserves memory to hold evacuations into young and old generations.  We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young).
> 
> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle.  In this case, we can share the young collector reserves with the old generation.  This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity.
> 
> The following spreadsheet snapshots highlight the benefits of this change.  In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time).  This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young.  This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC.  In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive.  The total number of GC cycles decreases significantly.
> 
> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a)
> 
> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles.  By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles.  This reduces CPU load.  The impact on response times is not as significant as with the 6G heap size.  We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100.
> 
> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f)
> 
> At 8G heap size, the GC is not at all stressed.  We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100.
> 
> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c)
> 
> The command line for these comparisons follows:
> 
> 
>             ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \
>                 -XX:+Unlock...

This pull request has been closed without being integrated.

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

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

From ayang at openjdk.org  Mon Jul 28 07:19:02 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 07:19:02 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v5]
In-Reply-To: <VnLSTr5JZTBzn1pkKeL1PP_8w6KS5aHeJEuXBbkmUBw=.2fb54f30-57ae-47be-adfb-2bf863219996@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <VnLSTr5JZTBzn1pkKeL1PP_8w6KS5aHeJEuXBbkmUBw=.2fb54f30-57ae-47be-adfb-2bf863219996@github.com>
Message-ID: <iDm2zh5pdQfOrhnh6ji_1chi_mw_Lw9NeUAnaMKxEkU=.39d518f8-bacc-4b8c-96ce-732f53bc3d64@github.com>

On Fri, 18 Jul 2025 13:14:38 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - Merge branch 'master' into sgc-roots
>  - review
>  - sgc-roots

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26038#issuecomment-3125858170

From ayang at openjdk.org  Mon Jul 28 07:19:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 07:19:03 GMT
Subject: Integrated: 8361055: Serial: Inline SerialHeap::process_roots
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: <OrSOiC3XmaUlPPPGC7017P0crRm6A3RIztDXPrYewiE=.86a9ecc8-c5b7-4a42-a09d-b032c9945d6a@github.com>

On Mon, 30 Jun 2025 08:25:09 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

This pull request has now been integrated.

Changeset: af5932ef
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af5932efb5e873ef3beb8b8999a5ef3fbd094ff6
Stats:     110 lines in 6 files changed: 31 ins; 48 del; 31 mod

8361055: Serial: Inline SerialHeap::process_roots

Reviewed-by: tschatzl, kbarrett, stefank

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

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

From tschatzl at openjdk.org  Mon Jul 28 07:58:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 07:58:54 GMT
Subject: RFR: 8364019: Add alignment precondition to Universe::reserve_heap
In-Reply-To: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
References: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
Message-ID: <hgRKq3AiGWMlQE7t9peF-jxurb_USRfgJ5iQa-5Oqxk=.94477a47-8b99-4c88-b9d1-141ba9c2dc85@github.com>

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

> Simple converting a redundant `align_up` to assert.
> 
> Test: tier1

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26456#pullrequestreview-3061025595

From tschatzl at openjdk.org  Mon Jul 28 08:00:01 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 08:00:01 GMT
Subject: RFR: 8363929: G1: Add G1 prefix to various G1 specific global
 locks [v2]
In-Reply-To: <ilwEpYERsK8SJ0OpEF7waXRuLy732SN-k8QYxIkR9d8=.e37fbbf0-ec78-478c-a72e-999616e2d509@github.com>
References: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
 <_dP0RIkEqBPbdMT-DFgI48v8f7thpVA4Ktgk9EX07o0=.accf3d10-e6a6-4b19-8c33-360b546a0365@github.com>
 <ilwEpYERsK8SJ0OpEF7waXRuLy732SN-k8QYxIkR9d8=.e37fbbf0-ec78-478c-a72e-999616e2d509@github.com>
Message-ID: <-2p47jzgGltpM7iqZhOAHJabVMckq5s623b0e1Jc0eA=.526eb64c-c4c1-4493-86f7-b5c83465d5af@github.com>

On Thu, 24 Jul 2025 11:05:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * shade review: fix mutex comments
>
> Looks fine!

Thanks @shipilev @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26444#issuecomment-3126006646

From tschatzl at openjdk.org  Mon Jul 28 08:00:02 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 08:00:02 GMT
Subject: Integrated: 8363929: G1: Add G1 prefix to various G1 specific global
 locks
In-Reply-To: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
References: <Vr-fNy04_uVFdBFbTjcYzmrDle7Topl_WTDXx8_pKR8=.06f5edec-b321-491f-8135-9cdee0c9b007@github.com>
Message-ID: <zxe3HTHMMt7BWL5uvSgcwucMyh4Y_mZrCcWvMPGsBpQ=.545ad9d7-4c1d-4c56-8f94-dc41857bc138@github.com>

On Wed, 23 Jul 2025 14:02:49 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this renaming of a few G1 specific locks to have a G1 prefix to make it clear that they should not be used elsewhere.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: bdc1ef20
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bdc1ef2021cc73d83607c1380ab7cd3a08353229
Stats:     61 lines in 9 files changed: 6 ins; 7 del; 48 mod

8363929: G1: Add G1 prefix to various G1 specific global locks

Reviewed-by: shade, ayang

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

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

From ayang at openjdk.org  Mon Jul 28 08:05:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 08:05:33 GMT
Subject: RFR: 8364166: Parallel: Remove the use of soft_ref_policy in Full GC
Message-ID: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>

Simple removing redundant soft-ref-clearing checking in full-gc, because Parallel already reacts to this particular gc-cause, `_wb_full_gc`.

Test: tier1-3

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

Commit messages:
 - pgc-soft-ref

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

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

From ayang at openjdk.org  Mon Jul 28 09:00:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 09:00:30 GMT
Subject: RFR: 8364176: Serial: Group all class unloading logc at the end of
 marking phase
Message-ID: <kTY3bfZzrTYX03I7HuEzGHn0QmeJmnoh6_6NPazsOkE=.54fc7b78-9bf1-499a-bac3-22f433348251@github.com>

Simple moving some classunloading logic inside `SerialFullGC`.

Test: tier1

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

Commit messages:
 - sgc-classunloading

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

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

From tschatzl at openjdk.org  Mon Jul 28 09:12:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 09:12:53 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v45]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <XXmA7QD5fE0Dbv8OtC5xjWw3PhHAnmgBqOh0NA_ftf4=.fbf19b93-d6ab-4efb-a6c4-28681595287c@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 62 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * remove unused G1DetachedRefinementStats_lock
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - 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
 - ... and 52 more: https://git.openjdk.org/jdk/compare/bdc1ef20...23aa2c8b

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=44
  Stats: 7123 lines in 112 files changed: 2588 ins; 3593 del; 942 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 tschatzl at openjdk.org  Mon Jul 28 11:29:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 11:29:56 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
Message-ID: <vwFtDSQ8D_Mnk9nA5XvIglfXZq-OwDKCuHRxdU8h6bI=.e3884f55-1c0f-4f8b-883e-72bbae8f2a60@github.com>

On Wed, 23 Jul 2025 07:15:21 GMT, Man Cao <manc at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - cleanup after merge
>>  - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact
>>  - Merge branch 'NormalizeTiming' into ConcCPUImpact
>>  - Thomas suggestion
>>  - Thomas Review
>>  - reorder
>>  - concurrent gc impact
>>  - clean out
>>  - init
>
> src/hotspot/share/gc/g1/g1Analytics.cpp line 174:
> 
>> 172:   // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
>> 173:   uint num_cpus = (uint)os::active_processor_count();
>> 174:   num_cpus = MIN2(num_cpus, MAX2(ConcGCThreads, ParallelGCThreads));
> 
> A minor issue is that `UseDynamicNumberOfGCThreads` may not activate all `ConcGCThreads`. I think it is acceptable the wall-clock time "lost" by mutator threads is a best-effort approximation anyway.

Fwiw, G1 has both `ConcGCThreads` (for marking; 1/4th of `ParallelGCThreads`) and `ConcRefinementThreads` (for refinement; equal in count with `ParallelGCThreads`) which are active at the same time.
Not sure if only using `ConcGCThreads` (`ParallelGCThreads`?) is appropriate for this calculation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2235739185

From tschatzl at openjdk.org  Mon Jul 28 11:29:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 11:29:57 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <vwFtDSQ8D_Mnk9nA5XvIglfXZq-OwDKCuHRxdU8h6bI=.e3884f55-1c0f-4f8b-883e-72bbae8f2a60@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <vwFtDSQ8D_Mnk9nA5XvIglfXZq-OwDKCuHRxdU8h6bI=.e3884f55-1c0f-4f8b-883e-72bbae8f2a60@github.com>
Message-ID: <NqgFS7vAiHjkvdl4-EegARKzxPWYG5gZVq8U2D6GPjY=.dc9be643-f168-464a-a977-8da3d7f3e46e@github.com>

On Mon, 28 Jul 2025 10:20:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Analytics.cpp line 174:
>> 
>>> 172:   // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
>>> 173:   uint num_cpus = (uint)os::active_processor_count();
>>> 174:   num_cpus = MIN2(num_cpus, MAX2(ConcGCThreads, ParallelGCThreads));
>> 
>> A minor issue is that `UseDynamicNumberOfGCThreads` may not activate all `ConcGCThreads`. I think it is acceptable the wall-clock time "lost" by mutator threads is a best-effort approximation anyway.
>
> Fwiw, G1 has both `ConcGCThreads` (for marking; 1/4th of `ParallelGCThreads`) and `ConcRefinementThreads` (for refinement; equal in count with `ParallelGCThreads`) which are active at the same time.
> Not sure if only using `ConcGCThreads` (`ParallelGCThreads`?) is appropriate for this calculation.

An alternative would be to consider concurrent cpu usage (`concurrent-cpu-usage`) as fraction of total cpu usage during the mutator phase (`total-cpu-usage-during-mutator`), and consider gc pause cpu usage as 100% total cpu usage during the pause (where `gc-pause-cpu-usage = #active processors * pause-duration`).

Ie. in total

  gc-time-ratio = (concurrent-cpu-usage + gc-pause-cpu-usage) / (total-cpu-usage-during-mutator + gc-pause-cpu-usage)

The dividend is G1 total cpu usage from end of previous GC to end of next GC, the divisor total cpu usage during the same time frame.


It may be a bit problematic wrt to changing active processors but it seems preferable to guessing the number of threads used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2235974815

From tschatzl at openjdk.org  Mon Jul 28 11:29:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 11:29:58 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
Message-ID: <D3_np30EZ4aQXxS1f5si7XOOAMa74i8ugmDOTo5zljc=.bf22c6bc-e0fe-44d5-a761-25446ac12789@github.com>

On Thu, 17 Jul 2025 13:16:29 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this patch which takes into account the impact of concurrent GC activity on mutator threads when computing the time spent on GC activity in a time interval. Previously, only the GC pause times were considered, and the overhead imposed by concurrent GC worker threads was not included.
>> 
>> With this change, we now estimate the impact of concurrent GC by dividing `elapsed_gc_cpu_time` by the number of CPUs. This provides an approximation of the additional time attributable to GC activity, assuming a fair CPU resource sharing.  Although this method does not account for contention on other shared resources (such as memory bandwidth or caches), it offers a reasonable estimate for most scenarios.
>> 
>> Testing: Tier 1
>
> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - cleanup after merge
>  - Merge remote-tracking branch 'upstream/master' into ConcCPUImpact
>  - Merge branch 'NormalizeTiming' into ConcCPUImpact
>  - Thomas suggestion
>  - Thomas Review
>  - reorder
>  - concurrent gc impact
>  - clean out
>  - init

src/hotspot/share/gc/g1/g1Analytics.hpp line 137:

> 135:   void set_concurrent_gc_cpu_time_ms(double ms) {
> 136:     _concurrent_gc_cpu_time_ms = ms;
> 137:   }

This method is unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2235527507

From tschatzl at openjdk.org  Mon Jul 28 11:29:59 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 11:29:59 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <ib9HzNBSe9HG_1feXoUmOvtZhrNQbG5uLxJF_2Tofjk=.e0a4e188-e2b3-42d3-95ff-c1c95c36f18f@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <Jl3NDY1cRCuV3MRX08XT502IQtcR-hKi2TFmjxJEYG0=.476fc8cc-e099-47f9-b2c3-55c72b869144@github.com>
 <ghu5Vei9ov6gyY1zxXU7EOXQwNAHMPR_WJzCUhurHko=.b6a9260c-f3e0-4522-ab08-ad7a906eacf8@github.com>
 <ib9HzNBSe9HG_1feXoUmOvtZhrNQbG5uLxJF_2Tofjk=.e0a4e188-e2b3-42d3-95ff-c1c95c36f18f@github.com>
Message-ID: <UqMiSMXaBTGJKD-2tx-UBqxXXC2MWrdhedJKMRrsovA=.b1792668-4b50-4ded-a501-897137c460cf@github.com>

On Thu, 24 Jul 2025 12:05:31 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Another issue seems to be that since both `record_pause_start()` and `record_pause()` are called for all pauses. It seems that this implementation only considers the concurrent CPU usage between Remark/Cleanup and Young pauses as G1 currently only resizes at Young collections.
>> 
>> The bulk of concurrent work is from Young -> Remark and Remark -> Cleanup though. If e.g. all of the concurrent cycles occurs between two Young GCs, that whole concurrent cycle seems to be lost in the calculation (or at least parts of the concurrent CPU usage)?
>> 
>> Or am I missing something?
>
> The assumption here is the `update_gc_pause_time_ratios` is called at the end of all GCs. The only issue I notice is that we don't call it in case of allocation_failures, which is problematic. But probably I don't understand the issue you are highlighting.

Actually I think there are two issues, let me copy from `G1Analytics::compute_pause_time_ratios`:


void G1Analytics::compute_pause_time_ratios(double end_time_sec, double pause_time_ms) {
[...]
  double short_interval_ms = (end_time_sec - most_recent_gc_end_time_sec()) * 1000.0;

  // This estimates the wall-clock time "lost" by application mutator threads due to concurrent GC
  // activity. We do not account for contention on other shared resources such as memory bandwidth and
  // caches, therefore underestimate the impact of the concurrent GC activity on mutator threads.
  uint num_cpus = (uint)os::active_processor_count();
  num_cpus = MIN2(num_cpus, ConcGCThreads);
  double concurrent_gc_impact_time = _concurrent_gc_cpu_time_ms / num_cpus;

  _short_term_pause_time_ratio = (pause_time_ms + concurrent_gc_impact_time) / short_interval_ms;
  _short_term_pause_time_ratio = clamp(_short_term_pause_time_ratio, 0.0, 1.0);
}

* the `short_term_pause_time_ratio` only takes the most recent `_concurrent_gc_cpu_time_ms` into account in this calculation. Between two Young GCs there may have been a complete concurrent cycle, which means that `_concurrent_gc_impact_time` only contains the concurrent work from the end of the Cleanup pause to the current Young GC. It does not seem to contain the concurrent work from the previous Young GC to the Cleanup pause, as `G1Policy::record_pause_start_time` _overwrites_ the last `G1Analytics::_concurrent_gc_cpu_time_ms`.

Just giving an idea how much concurrent time is missing here, running BRT (obviously this is to highlight the issue), printing the measured concurrent CPU time in `G1Policy::record_pause_start_time`:

[45.341s][info ][gc,start       ] GC(11) Pause Young (Concurrent Start) (G1 Evacuation Pause)
[45.341s][debug][gc             ] GC(11) conc cpu time: 8319.61 // This one is not really relevant here.
[...]
[48.821s][info ][gc,start       ] GC(12) Pause Remark
[48.821s][debug][gc             ] GC(12) conc cpu time: 11763.96
[...]
[50.146s][info ][gc,start       ] GC(12) Pause Cleanup
[50.146s][debug][gc             ] GC(12) conc cpu time: 5830.75
[...]
[54.987s][info ][gc,start       ] GC(13) Pause Young (Prepare Mixed) (G1 Evacuation Pause)
[54.987s][debug][gc             ] GC(13) conc cpu time: 2780.92


So in that last Young GC pause, only around 14% of actual concurrent CPU time between the most recent two Young GCs is is used to calculate short term pause time ratio afaict.

Looking a bit into the code, I think this is somewhat of a pre-existing issue. We always calculate short term pause time ratio based off the last GC pause regardless of type, i.e. in this case from Cleanup to the next Young. I am kind of doubting that this is correct right now.

Maybe this should be improved before this change?

Some additional issue:
* the `long_term_pause_time_ratio` does not take time taken by concurrent work into account afaict. Maybe it's hard, but there should be an explanation why.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2235731832

From jsikstro at openjdk.org  Mon Jul 28 12:33:52 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 28 Jul 2025 12:33:52 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v12]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <yPHekGSU4vWQYQBhdN4a8ZTn6TLnWAkGrKbVLufzN7I=.373d8bbf-864d-4a31-8ad7-813eb7b16d39@github.com>

> Hello,
> 
> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
> 
> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
> 
> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
> 
> Testing:
> * Oracle's tier 1-5

Joel Sikstr?m 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 15 additional commits since the last revision:

 - Merge branch 'master' into JDK-8358586_zallocator_cleanup
 - Make NONCOPYABLE(ZDeferredConstructed) private
 - Add template spacing and remove extra semicolon
 - Copyright year
 - Move definition of ZDeferredConstructed to inline header
 - Merge branch 'master' into JDK-8358586_zallocator_cleanup
 - Rework ZObjectAllocator
 - Private member variables in ZObjectAlloactorImpl
 - Move implementation to .cpp and static-only interface in .hpp
 - Consistent template friend style
 - ... and 5 more: https://git.openjdk.org/jdk/compare/5f88cd2b...1552e399

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/39958186..1552e399

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

  Stats: 58330 lines in 1735 files changed: 32369 ins; 15968 del; 9993 mod
  Patch: https://git.openjdk.org/jdk/pull/25693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25693/head:pull/25693

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

From tschatzl at openjdk.org  Mon Jul 28 13:39:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 13:39:39 GMT
Subject: RFR: 8364196: G1: Fix typo in "cset_groud_gid" local variable in
 G1FlushHumongousCandidateRemSets
Message-ID: <bFAX1eijluMYrCa7Ppd7FcI2xdwzQtH29p2rue5Gurg=.ac69c5db-d7de-4785-ac6d-9f71b294b52d@github.com>

Hi all,

  please review this fix to the typo "cset_groud_gid" which should mean "cset_group_id".

Testing: local compilation

Thanks,
  Thomas

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

Commit messages:
 - 8364196

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

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

From jsikstro at openjdk.org  Mon Jul 28 13:45:56 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 28 Jul 2025 13:45:56 GMT
Subject: RFR: 8364019: Add alignment precondition to Universe::reserve_heap
In-Reply-To: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
References: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
Message-ID: <_pKyd5T7jCFl-FgWdY0NqW5FtynSbjrsUqPdrDtzeyA=.7f1e9210-3889-43c6-b4e2-0cee6df92bda@github.com>

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

> Simple converting a redundant `align_up` to assert.
> 
> Test: tier1

Looks good.

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

Marked as reviewed by jsikstro (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26456#pullrequestreview-3062830022

From ayang at openjdk.org  Mon Jul 28 14:18:56 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 14:18:56 GMT
Subject: RFR: 8364196: G1: Fix typo in "cset_groud_gid" local variable in
 G1FlushHumongousCandidateRemSets
In-Reply-To: <bFAX1eijluMYrCa7Ppd7FcI2xdwzQtH29p2rue5Gurg=.ac69c5db-d7de-4785-ac6d-9f71b294b52d@github.com>
References: <bFAX1eijluMYrCa7Ppd7FcI2xdwzQtH29p2rue5Gurg=.ac69c5db-d7de-4785-ac6d-9f71b294b52d@github.com>
Message-ID: <-Y8j4euDZluskY8n-YUSN1Ut-lNPh-Dew6T3HsSgwwU=.f01c1ab9-6d04-4416-92a1-8a1a71e3ba64@github.com>

On Mon, 28 Jul 2025 13:34:29 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to the typo "cset_groud_gid" which should mean "cset_group_id".
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26505#pullrequestreview-3063004940

From ayang at openjdk.org  Mon Jul 28 14:22:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 14:22:00 GMT
Subject: RFR: 8364019: Add alignment precondition to Universe::reserve_heap
In-Reply-To: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
References: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
Message-ID: <FaCJf1ln2G1nYqedc2VwQlgPraB7U8l0SvRnzpB4H_g=.92ea7254-11f1-40ab-9d53-26d40a8e46c6@github.com>

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

> Simple converting a redundant `align_up` to assert.
> 
> Test: tier1

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26456#issuecomment-3127448977

From ayang at openjdk.org  Mon Jul 28 14:22:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 14:22:00 GMT
Subject: Integrated: 8364019: Add alignment precondition to
 Universe::reserve_heap
In-Reply-To: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
References: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
Message-ID: <FhlqD8SA4V0a6Vi2Pc3Zj2-OQkJU_uWgazPP9v0HgsQ=.c3ca73a4-3371-4662-a526-90d5cefdad85@github.com>

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

> Simple converting a redundant `align_up` to assert.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 70ebb5e8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70ebb5e8c9d99e17e84da798fed01626bc7f9ea0
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8364019: Add alignment precondition to Universe::reserve_heap

Reviewed-by: tschatzl, jsikstro

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

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

From shade at openjdk.org  Mon Jul 28 15:38:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 15:38:39 GMT
Subject: RFR: 8364183: Shenandoah: Improve commit/uncommit handling
Message-ID: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>

While working on related bug, I found that Shenandoah commit/uncommit code has a few issues:
 1. It throws Java OOME on commit/uncommit failures. These should actually be VM-level out of memory errors, so they are properly fatal.
 2. Throwing OOME on uncommit looks fairly weird.
 3. We are not zapping on the newly committed regions. 

Additional testing:
 - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
 - [ ] Linux x86_64 server fastdebug, `all`  + `-XX:+UseShenandoahGC`

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/26502/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26502&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364183
  Stats: 59 lines in 3 files changed: 20 ins; 14 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/26502.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26502/head:pull/26502

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

From shade at openjdk.org  Mon Jul 28 15:48:27 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 15:48:27 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading
Message-ID: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>

As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
 - [x] Linux x86_64 server fastdebug, `runtime/cds`
 - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
 - [ ] Linux x86_64 server fastdebug, `all`

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

Commit messages:
 - Fix
 - Fix
 - Regular CDS

Changes: https://git.openjdk.org/jdk/pull/26510/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26510&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364212
  Stats: 107 lines in 6 files changed: 35 ins; 35 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/26510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26510/head:pull/26510

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

From duke at openjdk.org  Mon Jul 28 16:56:40 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 28 Jul 2025 16:56:40 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v3]
In-Reply-To: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
Message-ID: <015QerKdqaYNxPZqV0g71SJN1NLA9Qbisj3V1_bdMvY=.3efd7968-e15c-4018-a64c-7959b4dc1da6@github.com>

> Fix missing `increment_total_collections` usages in Shenandoah (otherwise, the invocation count is always 0 as shown in https://github.com/openjdk/jdk/pull/26272 overview). 
> 
> Also added some generational information for generational shenandoah logging.
> 
> Shenandoah logging samples:
> 
> 
> ######################
> Shenandoah - Beore GC
> ######################
> [0.161s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.161s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.161s][debug][gc,heap      ] GC(0)    100M max, 100M soft max, 100M committed, 40312K used
> [0.161s][debug][gc,heap      ] GC(0)   400 x 256K regions
> [0.161s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.161s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.161s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.161s][debug][gc,heap      ] GC(0)  Collection set:
> [0.161s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.161s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.161s][debug][gc,heap      ] GC(0) 
> [0.161s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.161s][debug][gc,metaspace ] GC(0)  Metaspace       used 86K, committed 320K, reserved 1114112K
> [0.161s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> ######################
> Shenandoah - After GC
> ######################
> [2.179s][debug][gc,heap        ] GC(9) Heap After GC invocations=17 (full 7):
> [2.179s][debug][gc,heap        ] GC(9)  Shenandoah Heap
> [2.179s][debug][gc,heap        ] GC(9)    100M max, 100M soft max, 100M committed, 97113K used
> [2.179s][debug][gc,heap        ] GC(9)   400 x 256K regions
> [2.179s][debug][gc,heap        ] GC(9)  Status: not cancelled
> [2.179s][debug][gc,heap        ] GC(9)  Reserved region:
> [2.179s][debug][gc,heap        ] GC(9)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.179s][debug][gc,heap        ] GC(9)  Collection set:
> [2.179s][debug][gc,heap        ] GC(9)   - map (vanilla): 0x0000000000004e70
> [2.179s][debug][gc,heap        ] GC(9)   - map (biased):  0x0000000000001000
> [2.179s][debug][gc,heap        ] GC(9) 
> [2.179s][debug][gc,metaspace   ] GC(9) Metaspace After GC invocations=17 (full 7):
> [2.179s][debug][gc,metaspace   ] GC(9)  Metaspace       used 125K, committed 320K, reserved 1114112K
> [2.179s][debug][gc,metaspace   ] GC(9)   class space    used 4K, committed 128K, reserved 1048576K
> 
> 
> Generational Shenandoah logging samples
> 
> #############...

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

  const & print

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26469/files
  - new: https://git.openjdk.org/jdk/pull/26469/files/1d51fcff..ed455a80

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

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

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

From duke at openjdk.org  Mon Jul 28 17:06:00 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 28 Jul 2025 17:06:00 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v2]
In-Reply-To: <_Zy6ZBdYt_pCQQKo0i_l5LCMHuvScalqFepGE3Am4Bo=.a511d094-23ad-44f4-a6ab-3775885cd6f7@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
 <fAGEZNI-5QjutT5CW-5P4jylB7-UjrrTNocL9zgtckc=.c51c903e-606c-4a09-82a7-41220c65bd5e@github.com>
 <_Zy6ZBdYt_pCQQKo0i_l5LCMHuvScalqFepGE3Am4Bo=.a511d094-23ad-44f4-a6ab-3775885cd6f7@github.com>
Message-ID: <9wfu8nUzcu62SCptG4yPb6P5sr0i1uZbDtfKHyWbM8I=.6a164626-a377-44c2-9df5-ec4c92a1e9d7@github.com>

On Fri, 25 Jul 2025 21:56:49 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> I am wondering if we could just hoist the incrementing of the collections count to run_gc_cycle() which would normally take care of everything at once in one place, with the option true for stw and full cases.

I thought about moving them into `run_gc_cycle()` actually. However, some of the gc runs can be cancelled: 

https://github.com/openjdk/jdk/blob/ed455a803961f412c9e5855ec409e45980d64d00/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp#L284-L286

While the total collection means collections that have been "started":

https://github.com/openjdk/jdk/blob/f53d0519b9a3a6eaf64fb938dfedc09795ac31f8/src/hotspot/share/gc/shared/collectedHeap.hpp#L389

So we have to put them into each individual method.


Updated for the other two comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/26469#issuecomment-3128171200

From ysr at openjdk.org  Mon Jul 28 19:10:53 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 28 Jul 2025 19:10:53 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v2]
In-Reply-To: <9wfu8nUzcu62SCptG4yPb6P5sr0i1uZbDtfKHyWbM8I=.6a164626-a377-44c2-9df5-ec4c92a1e9d7@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
 <fAGEZNI-5QjutT5CW-5P4jylB7-UjrrTNocL9zgtckc=.c51c903e-606c-4a09-82a7-41220c65bd5e@github.com>
 <_Zy6ZBdYt_pCQQKo0i_l5LCMHuvScalqFepGE3Am4Bo=.a511d094-23ad-44f4-a6ab-3775885cd6f7@github.com>
 <9wfu8nUzcu62SCptG4yPb6P5sr0i1uZbDtfKHyWbM8I=.6a164626-a377-44c2-9df5-ec4c92a1e9d7@github.com>
Message-ID: <EOWIM1hl9pXFfbF7XF7YmZbbBGIzGZMLshU8BxOabg0=.3fa50414-b2e4-424c-a587-59a9a15c79db@github.com>

On Mon, 28 Jul 2025 17:03:04 GMT, Rui Li <duke at openjdk.org> wrote:

> > I am wondering if we could just hoist the incrementing of the collections count to run_gc_cycle() which would normally take care of everything at once in one place, with the option true for stw and full cases.
> 
> I thought about moving them into `run_gc_cycle()` actually. However, some of the gc runs can be cancelled:
> 
> https://github.com/openjdk/jdk/blob/ed455a803961f412c9e5855ec409e45980d64d00/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp#L284-L286
> 
> While the total collection means collections that have been "started":
> 
> https://github.com/openjdk/jdk/blob/f53d0519b9a3a6eaf64fb938dfedc09795ac31f8/src/hotspot/share/gc/shared/collectedHeap.hpp#L389
> 
> So we have to put them into each individual method.

Interesting. Would it work to put the incrementing inside the `ShenandoahGCSession` constructor, or would there be issues with that in terms of something for which the counts would go awry in some cases?

> 
> Updated for the other two comments.

Thanks, those look good!

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

PR Comment: https://git.openjdk.org/jdk/pull/26469#issuecomment-3128710666

From duke at openjdk.org  Mon Jul 28 20:05:54 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 28 Jul 2025 20:05:54 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v2]
In-Reply-To: <EOWIM1hl9pXFfbF7XF7YmZbbBGIzGZMLshU8BxOabg0=.3fa50414-b2e4-424c-a587-59a9a15c79db@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
 <fAGEZNI-5QjutT5CW-5P4jylB7-UjrrTNocL9zgtckc=.c51c903e-606c-4a09-82a7-41220c65bd5e@github.com>
 <_Zy6ZBdYt_pCQQKo0i_l5LCMHuvScalqFepGE3Am4Bo=.a511d094-23ad-44f4-a6ab-3775885cd6f7@github.com>
 <9wfu8nUzcu62SCptG4yPb6P5sr0i1uZbDtfKHyWbM8I=.6a164626-a377-44c2-9df5-ec4c92a1e9d7@github.com>
 <EOWIM1hl9pXFfbF7XF7YmZbbBGIzGZMLshU8BxOabg0=.3fa50414-b2e4-424c-a587-59a9a15c79db@github.com>
Message-ID: <5ZdkHTJ1p5gQjawcQ3c7AmOn5aRv3J7wx2GuZTPWRq4=.97033335-78d3-4a80-8d66-4a8fef92e8d2@github.com>

On Mon, 28 Jul 2025 19:07:44 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Would it work to put the incrementing inside the ShenandoahGCSession constructor

That's another good consolidated place, but that seems to be agnostic about whether it's full gc or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/26469#issuecomment-3129252926

From ysr at openjdk.org  Mon Jul 28 20:34:54 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 28 Jul 2025 20:34:54 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v3]
In-Reply-To: <015QerKdqaYNxPZqV0g71SJN1NLA9Qbisj3V1_bdMvY=.3efd7968-e15c-4018-a64c-7959b4dc1da6@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
 <015QerKdqaYNxPZqV0g71SJN1NLA9Qbisj3V1_bdMvY=.3efd7968-e15c-4018-a64c-7959b4dc1da6@github.com>
Message-ID: <f7jOhSPar7tsDMKSNNb31mtSWsLOJ9t4cVagXjegtD8=.cb63c815-5fed-468a-901f-db37c4b24b36@github.com>

On Mon, 28 Jul 2025 16:56:40 GMT, Rui Li <duke at openjdk.org> wrote:

>> Fix missing `increment_total_collections` usages in Shenandoah (otherwise, the invocation count is always 0 as shown in https://github.com/openjdk/jdk/pull/26272 overview). 
>> 
>> Also added some generational information for generational shenandoah logging.
>> 
>> Shenandoah logging samples:
>> 
>> 
>> ######################
>> Shenandoah - Before GC
>> ######################
>> [0.161s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,heap      ] GC(0)  Shenandoah Heap
>> [0.161s][debug][gc,heap      ] GC(0)    100M max, 100M soft max, 100M committed, 40312K used
>> [0.161s][debug][gc,heap      ] GC(0)   400 x 256K regions
>> [0.161s][debug][gc,heap      ] GC(0)  Status: not cancelled
>> [0.161s][debug][gc,heap      ] GC(0)  Reserved region:
>> [0.161s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [0.161s][debug][gc,heap      ] GC(0)  Collection set:
>> [0.161s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
>> [0.161s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
>> [0.161s][debug][gc,heap      ] GC(0) 
>> [0.161s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,metaspace ] GC(0)  Metaspace       used 86K, committed 320K, reserved 1114112K
>> [0.161s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
>> 
>> ######################
>> Shenandoah - After GC
>> ######################
>> [2.179s][debug][gc,heap        ] GC(9) Heap After GC invocations=17 (full 7):
>> [2.179s][debug][gc,heap        ] GC(9)  Shenandoah Heap
>> [2.179s][debug][gc,heap        ] GC(9)    100M max, 100M soft max, 100M committed, 97113K used
>> [2.179s][debug][gc,heap        ] GC(9)   400 x 256K regions
>> [2.179s][debug][gc,heap        ] GC(9)  Status: not cancelled
>> [2.179s][debug][gc,heap        ] GC(9)  Reserved region:
>> [2.179s][debug][gc,heap        ] GC(9)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [2.179s][debug][gc,heap        ] GC(9)  Collection set:
>> [2.179s][debug][gc,heap        ] GC(9)   - map (vanilla): 0x0000000000004e70
>> [2.179s][debug][gc,heap        ] GC(9)   - map (biased):  0x0000000000001000
>> [2.179s][debug][gc,heap        ] GC(9) 
>> [2.179s][debug][gc,metaspace   ] GC(9) Metaspace After GC invocations=17 (full 7):
>> [2.179s][debug][gc,metaspace   ] GC(9)  Metaspace       used 125K, committed 320K, reserved 1114112K
>> [2.179s][debug][gc,metaspace   ] GC(9)   class space    used 4K, commi...
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   const & print

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26469#pullrequestreview-3064549890

From ysr at openjdk.org  Mon Jul 28 20:34:54 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 28 Jul 2025 20:34:54 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v2]
In-Reply-To: <5ZdkHTJ1p5gQjawcQ3c7AmOn5aRv3J7wx2GuZTPWRq4=.97033335-78d3-4a80-8d66-4a8fef92e8d2@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
 <fAGEZNI-5QjutT5CW-5P4jylB7-UjrrTNocL9zgtckc=.c51c903e-606c-4a09-82a7-41220c65bd5e@github.com>
 <_Zy6ZBdYt_pCQQKo0i_l5LCMHuvScalqFepGE3Am4Bo=.a511d094-23ad-44f4-a6ab-3775885cd6f7@github.com>
 <9wfu8nUzcu62SCptG4yPb6P5sr0i1uZbDtfKHyWbM8I=.6a164626-a377-44c2-9df5-ec4c92a1e9d7@github.com>
 <EOWIM1hl9pXFfbF7XF7YmZbbBGIzGZMLshU8BxOabg0=.3fa50414-b2e4-424c-a587-59a9a15c79db@github.com>
 <5ZdkHTJ1p5gQjawcQ3c7AmOn5aRv3J7wx2GuZTPWRq4=.97033335-78d3-4a80-8d66-4a8fef92e8d2@github.com>
Message-ID: <aCdER6_gmescECIakqTfTKua_hLdfzMA2h9qIQtNaGQ=.f8b1cd11-fa93-4cae-aac8-e9c5c87bdb54@github.com>

On Mon, 28 Jul 2025 20:01:28 GMT, Rui Li <duke at openjdk.org> wrote:

> > Would it work to put the incrementing inside the ShenandoahGCSession constructor
> 
> That's another good consolidated place, but that seems to be not fully aware if it's a full gc or not with GCCause value?

I see, thanks for checking. May be we can try and clean up some of this at a later time such as to enable consolidation.

Reviewed!

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

PR Comment: https://git.openjdk.org/jdk/pull/26469#issuecomment-3129622040

From duke at openjdk.org  Mon Jul 28 21:17:55 2025
From: duke at openjdk.org (duke)
Date: Mon, 28 Jul 2025 21:17:55 GMT
Subject: RFR: 8364081: Shenandoah & GenShen logging improvement [v3]
In-Reply-To: <015QerKdqaYNxPZqV0g71SJN1NLA9Qbisj3V1_bdMvY=.3efd7968-e15c-4018-a64c-7959b4dc1da6@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
 <015QerKdqaYNxPZqV0g71SJN1NLA9Qbisj3V1_bdMvY=.3efd7968-e15c-4018-a64c-7959b4dc1da6@github.com>
Message-ID: <BW-xkjgV_KcVR1sflQNWupeRAYx_sbb_imtAmChg_n8=.1d6eee33-5c34-4a74-aab8-bfc76155253f@github.com>

On Mon, 28 Jul 2025 16:56:40 GMT, Rui Li <duke at openjdk.org> wrote:

>> Fix missing `increment_total_collections` usages in Shenandoah (otherwise, the invocation count is always 0 as shown in https://github.com/openjdk/jdk/pull/26272 overview). 
>> 
>> Also added some generational information for generational shenandoah logging.
>> 
>> Shenandoah logging samples:
>> 
>> 
>> ######################
>> Shenandoah - Before GC
>> ######################
>> [0.161s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,heap      ] GC(0)  Shenandoah Heap
>> [0.161s][debug][gc,heap      ] GC(0)    100M max, 100M soft max, 100M committed, 40312K used
>> [0.161s][debug][gc,heap      ] GC(0)   400 x 256K regions
>> [0.161s][debug][gc,heap      ] GC(0)  Status: not cancelled
>> [0.161s][debug][gc,heap      ] GC(0)  Reserved region:
>> [0.161s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [0.161s][debug][gc,heap      ] GC(0)  Collection set:
>> [0.161s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
>> [0.161s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
>> [0.161s][debug][gc,heap      ] GC(0) 
>> [0.161s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
>> [0.161s][debug][gc,metaspace ] GC(0)  Metaspace       used 86K, committed 320K, reserved 1114112K
>> [0.161s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
>> 
>> ######################
>> Shenandoah - After GC
>> ######################
>> [2.179s][debug][gc,heap        ] GC(9) Heap After GC invocations=17 (full 7):
>> [2.179s][debug][gc,heap        ] GC(9)  Shenandoah Heap
>> [2.179s][debug][gc,heap        ] GC(9)    100M max, 100M soft max, 100M committed, 97113K used
>> [2.179s][debug][gc,heap        ] GC(9)   400 x 256K regions
>> [2.179s][debug][gc,heap        ] GC(9)  Status: not cancelled
>> [2.179s][debug][gc,heap        ] GC(9)  Reserved region:
>> [2.179s][debug][gc,heap        ] GC(9)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [2.179s][debug][gc,heap        ] GC(9)  Collection set:
>> [2.179s][debug][gc,heap        ] GC(9)   - map (vanilla): 0x0000000000004e70
>> [2.179s][debug][gc,heap        ] GC(9)   - map (biased):  0x0000000000001000
>> [2.179s][debug][gc,heap        ] GC(9) 
>> [2.179s][debug][gc,metaspace   ] GC(9) Metaspace After GC invocations=17 (full 7):
>> [2.179s][debug][gc,metaspace   ] GC(9)  Metaspace       used 125K, committed 320K, reserved 1114112K
>> [2.179s][debug][gc,metaspace   ] GC(9)   class space    used 4K, commi...
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   const & print

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26469#issuecomment-3129909453

From duke at openjdk.org  Mon Jul 28 23:32:07 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 28 Jul 2025 23:32:07 GMT
Subject: Integrated: 8364081: Shenandoah & GenShen logging improvement
In-Reply-To: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
References: <5ZUfAQ9nMtpZKNalxjqnUdA_MII_gj5Daqn7LbiS8Vs=.d50995fc-292a-46f2-bf25-8ce58b80c849@github.com>
Message-ID: <KeRtfWroTLiAqm6aZ-s30EFttgIEBH54wRyfRwb3DNo=.51e17829-5fa9-406c-b565-0c9bd90b4f72@github.com>

On Fri, 25 Jul 2025 01:30:59 GMT, Rui Li <duke at openjdk.org> wrote:

> Fix missing `increment_total_collections` usages in Shenandoah (otherwise, the invocation count is always 0 as shown in https://github.com/openjdk/jdk/pull/26272 overview). 
> 
> Also added some generational information for generational shenandoah logging.
> 
> Shenandoah logging samples:
> 
> 
> ######################
> Shenandoah - Before GC
> ######################
> [0.161s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.161s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.161s][debug][gc,heap      ] GC(0)    100M max, 100M soft max, 100M committed, 40312K used
> [0.161s][debug][gc,heap      ] GC(0)   400 x 256K regions
> [0.161s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.161s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.161s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.161s][debug][gc,heap      ] GC(0)  Collection set:
> [0.161s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.161s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.161s][debug][gc,heap      ] GC(0) 
> [0.161s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.161s][debug][gc,metaspace ] GC(0)  Metaspace       used 86K, committed 320K, reserved 1114112K
> [0.161s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> ######################
> Shenandoah - After GC
> ######################
> [2.179s][debug][gc,heap        ] GC(9) Heap After GC invocations=17 (full 7):
> [2.179s][debug][gc,heap        ] GC(9)  Shenandoah Heap
> [2.179s][debug][gc,heap        ] GC(9)    100M max, 100M soft max, 100M committed, 97113K used
> [2.179s][debug][gc,heap        ] GC(9)   400 x 256K regions
> [2.179s][debug][gc,heap        ] GC(9)  Status: not cancelled
> [2.179s][debug][gc,heap        ] GC(9)  Reserved region:
> [2.179s][debug][gc,heap        ] GC(9)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.179s][debug][gc,heap        ] GC(9)  Collection set:
> [2.179s][debug][gc,heap        ] GC(9)   - map (vanilla): 0x0000000000004e70
> [2.179s][debug][gc,heap        ] GC(9)   - map (biased):  0x0000000000001000
> [2.179s][debug][gc,heap        ] GC(9) 
> [2.179s][debug][gc,metaspace   ] GC(9) Metaspace After GC invocations=17 (full 7):
> [2.179s][debug][gc,metaspace   ] GC(9)  Metaspace       used 125K, committed 320K, reserved 1114112K
> [2.179s][debug][gc,metaspace   ] GC(9)   class space    used 4K, committed 128K, reserved 1048576K
> 
> 
> Generational Shenandoah logging samples
> 
> ############...

This pull request has now been integrated.

Changeset: 3e4e5dd0
Author:    Rui Li <ruiamzn at amazon.com>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e4e5dd06f8a74ada792e5d03b4604adcf618a4a
Stats:     39 lines in 4 files changed: 27 ins; 0 del; 12 mod

8364081: Shenandoah & GenShen logging improvement

Reviewed-by: ysr, wkemper

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

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

From wkemper at openjdk.org  Tue Jul 29 00:39:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 29 Jul 2025 00:39:00 GMT
Subject: RFR: 8364183: Shenandoah: Improve commit/uncommit handling
In-Reply-To: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
References: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
Message-ID: <gHFlGms1TX8hOSAugi3FgQGrZlFL7gB-Mw7dhSh39FU=.b6608d0f-28c5-4a35-9576-8d4a300440a6@github.com>

On Mon, 28 Jul 2025 10:34:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While working on related bug, I found that Shenandoah commit/uncommit code has a few issues:
>  1. It throws Java OOME on commit/uncommit failures. These should actually be VM-level out of memory errors, so they are properly fatal.
>  2. Throwing OOME on uncommit looks fairly weird.
>  3. We are not zapping on the newly committed regions. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `all`  + `-XX:+UseShenandoahGC`

LGTM

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26502#pullrequestreview-3064858769

From stuefe at openjdk.org  Tue Jul 29 04:41:30 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 04:41:30 GMT
Subject: RFR: 8364159: Shenandoah assertions after JDK-8361712
Message-ID: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>

In `ShenandoahAsserts::extract_klass_safely`, we attempt to carefully extract the Klass for an object and trip over our own feet doing this. We load the Markword twice: once to read "is_marked" and get the forwardee, once to extract the narrowKlass.

If between the first and the second load we did evacuate the object concurrently, this happens:

T1 : fwd = SheandoahForwarding::get_forwardee_raw_unchecked(obj)  => obj unmarked => (fwd == obj)
T2 : (installs forwarding pointer in obj)
T1: read markword from fwd again, (fwd == obj) => reads markword from forwarded obj, interprets the zeros in the upper part of the forwardee address as narrowKlass == 0, asserts

The solution is - as ShenandoahForwarding::klass() already does - to load the MW from original obj only once. Patch does that.

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

Commit messages:
 - start

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

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

From stuefe at openjdk.org  Tue Jul 29 04:41:30 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 04:41:30 GMT
Subject: RFR: 8364159: Shenandoah assertions after JDK-8361712
In-Reply-To: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>
References: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>
Message-ID: <Las35DYljkVY3vGJxXl3rfz4q2U0Et0FAD9s-Y9RLAc=.3e004701-b633-42ea-90b0-96dd153d9683@github.com>

On Mon, 28 Jul 2025 16:49:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `ShenandoahAsserts::extract_klass_safely`, we attempt to carefully extract the Klass for an object and trip over our own feet doing this. We load the Markword twice: once to read "is_marked" and get the forwardee, once to extract the narrowKlass.
> 
> If between the first and the second load we did evacuate the object concurrently, this happens:
> 
> T1 : fwd = SheandoahForwarding::get_forwardee_raw_unchecked(obj)  => obj unmarked => (fwd == obj)
> T2 : (installs forwarding pointer in obj)
> T1: read markword from fwd again, (fwd == obj) => reads markword from forwarded obj, interprets the zeros in the upper part of the forwardee address as narrowKlass == 0, asserts
> 
> The solution is - as ShenandoahForwarding::klass() already does - to load the MW from original obj only once. Patch does that.

MacOS error unrelated

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

PR Comment: https://git.openjdk.org/jdk/pull/26513#issuecomment-3130655743

From tschatzl at openjdk.org  Tue Jul 29 07:45:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Jul 2025 07:45:53 GMT
Subject: RFR: 8364176: Serial: Group all class unloading logc at the end of
 marking phase
In-Reply-To: <kTY3bfZzrTYX03I7HuEzGHn0QmeJmnoh6_6NPazsOkE=.54fc7b78-9bf1-499a-bac3-22f433348251@github.com>
References: <kTY3bfZzrTYX03I7HuEzGHn0QmeJmnoh6_6NPazsOkE=.54fc7b78-9bf1-499a-bac3-22f433348251@github.com>
Message-ID: <a2WdOxBlmNjyazRiRyRaO6N7lkopD2ni66uaHWl1LhA=.925df147-d563-42b5-b239-002604c54946@github.com>

On Mon, 28 Jul 2025 08:54:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple moving some classunloading logic inside `SerialFullGC`.
> 
> Test: tier1

Seems good.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26499#pullrequestreview-3066005425

From tschatzl at openjdk.org  Tue Jul 29 08:10:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Jul 2025 08:10:58 GMT
Subject: RFR: 8364166: Parallel: Remove the use of soft_ref_policy in Full
 GC
In-Reply-To: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
References: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
Message-ID: <TosaxmGOvi_oupHvaJqaSv64VIwuPEf7ame0tjH9_-g=.512ba65d-3fcf-4df4-afb5-0378df9d8b6f@github.com>

On Mon, 28 Jul 2025 08:00:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing redundant soft-ref-clearing checking in full-gc, because Parallel already reacts to this particular gc-cause, `_wb_full_gc`.
> 
> Test: tier1-3

Changes requested by tschatzl (Reviewer).

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

> 982:   clear_all_soft_refs = clear_all_soft_refs
> 983:                      || heap->soft_ref_policy()->should_clear_all_soft_refs();
> 984: 

* the comment for this method needs to be fixed
* the CR description in JIRA should be clarified. This change does not remove all occurrences of `_soft_ref_policy` in Parallel.
* the parameter name `clear_all_soft_refs` in the declaration and the definition are different

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

PR Review: https://git.openjdk.org/jdk/pull/26496#pullrequestreview-3066111354
PR Review Comment: https://git.openjdk.org/jdk/pull/26496#discussion_r2238910328

From ayang at openjdk.org  Tue Jul 29 08:20:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 29 Jul 2025 08:20:35 GMT
Subject: RFR: 8364166: Parallel: Remove the use of soft_ref_policy in Full
 GC [v2]
In-Reply-To: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
References: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
Message-ID: <HD7TOLCfwzE7FmH-92RGKc8O6epNbJQwaHUuacE3jXk=.7aef4544-bbdd-4a38-9ef9-866a4ab11391@github.com>

> Simple removing redundant soft-ref-clearing checking in full-gc, because Parallel already reacts to this particular gc-cause, `_wb_full_gc`.
> 
> 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 three additional commits since the last revision:

 - review
 - Merge branch 'master' into pgc-soft-ref
 - pgc-soft-ref

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26496/files
  - new: https://git.openjdk.org/jdk/pull/26496/files/5d8f5956..ccef2df1

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

  Stats: 1144 lines in 37 files changed: 604 ins; 386 del; 154 mod
  Patch: https://git.openjdk.org/jdk/pull/26496.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26496/head:pull/26496

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

From tschatzl at openjdk.org  Tue Jul 29 08:21:09 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Jul 2025 08:21:09 GMT
Subject: RFR: 8364249: G1: Fix some comments about "maximum_collection"
Message-ID: <iwS3YYyLMBJTQ4k6gERcdJfUEsn5tgSUpJBJjT5bomo=.12d4ad8e-dd66-47c2-ac4b-ccdcb8c9b72b@github.com>

Hi all,

  please review this trivial comment change to have them adhere to the formal parameter specification.

Testing: local compilation

Thanks,
  Thomas

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

Commit messages:
 - 8364249

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

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

From tschatzl at openjdk.org  Tue Jul 29 08:34:55 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Jul 2025 08:34:55 GMT
Subject: RFR: 8364166: Parallel: Remove the use of soft_ref_policy in Full
 GC [v2]
In-Reply-To: <HD7TOLCfwzE7FmH-92RGKc8O6epNbJQwaHUuacE3jXk=.7aef4544-bbdd-4a38-9ef9-866a4ab11391@github.com>
References: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
 <HD7TOLCfwzE7FmH-92RGKc8O6epNbJQwaHUuacE3jXk=.7aef4544-bbdd-4a38-9ef9-866a4ab11391@github.com>
Message-ID: <I3nOLYj__XH8vIUhCzWELo6Y_baNUcQsO-y2bHoPwSw=.de87fd6b-e3af-4804-9472-a8c0e476105f@github.com>

On Tue, 29 Jul 2025 08:20:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple removing redundant soft-ref-clearing checking in full-gc, because Parallel already reacts to this particular gc-cause, `_wb_full_gc`.
>> 
>> 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 three additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-soft-ref
>  - pgc-soft-ref

Marked as reviewed by tschatzl (Reviewer).

src/hotspot/share/gc/parallel/psParallelCompact.hpp line 765:

> 763: 
> 764:   static bool invoke(bool clear_all_soft_refs);
> 765:   static bool invoke_no_policy(bool clear_all_soft_refs);

I would prefer to keep using `maximum_heap_compaction` as `clear_all_soft_refs` seems too specific. However I am not insisting on this.

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

PR Review: https://git.openjdk.org/jdk/pull/26496#pullrequestreview-3066225226
PR Review Comment: https://git.openjdk.org/jdk/pull/26496#discussion_r2238977946

From tschatzl at openjdk.org  Tue Jul 29 08:34:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Jul 2025 08:34:57 GMT
Subject: RFR: 8364166: Parallel: Remove the use of soft_ref_policy in Full
 GC [v2]
In-Reply-To: <TosaxmGOvi_oupHvaJqaSv64VIwuPEf7ame0tjH9_-g=.512ba65d-3fcf-4df4-afb5-0378df9d8b6f@github.com>
References: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
 <TosaxmGOvi_oupHvaJqaSv64VIwuPEf7ame0tjH9_-g=.512ba65d-3fcf-4df4-afb5-0378df9d8b6f@github.com>
Message-ID: <scn0n2t4Amr9eSqhItuuS_8a9D3ZMDUyE9dZQ4YHRXg=.2e593224-dbc0-4244-92ac-3b17845a2ed6@github.com>

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

>     * the CR description in JIRA should be clarified. This change does not remove all occurrences of `_soft_ref_policy` in Parallel.

It does. `_soft_ref_policy` should probably be moved to the collectors actually using it (before cleaning up its use, I think similar changes can be done for G1 and Serial)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26496#discussion_r2238974614

From ayang at openjdk.org  Tue Jul 29 08:54:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 29 Jul 2025 08:54:58 GMT
Subject: RFR: 8364166: Parallel: Remove the use of soft_ref_policy in Full
 GC [v2]
In-Reply-To: <I3nOLYj__XH8vIUhCzWELo6Y_baNUcQsO-y2bHoPwSw=.de87fd6b-e3af-4804-9472-a8c0e476105f@github.com>
References: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
 <HD7TOLCfwzE7FmH-92RGKc8O6epNbJQwaHUuacE3jXk=.7aef4544-bbdd-4a38-9ef9-866a4ab11391@github.com>
 <I3nOLYj__XH8vIUhCzWELo6Y_baNUcQsO-y2bHoPwSw=.de87fd6b-e3af-4804-9472-a8c0e476105f@github.com>
Message-ID: <4Q8z5Nqiby6YssBNb6GzTVZGwx6H4QebeCFTSKL3tSU=.a8e42fbb-b666-44ac-a948-f51538e65b86@github.com>

On Tue, 29 Jul 2025 08:32:10 GMT, Thomas Schatzl <tschatzl 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-soft-ref
>>  - pgc-soft-ref
>
> src/hotspot/share/gc/parallel/psParallelCompact.hpp line 765:
> 
>> 763: 
>> 764:   static bool invoke(bool clear_all_soft_refs);
>> 765:   static bool invoke_no_policy(bool clear_all_soft_refs);
> 
> I would prefer to keep using `maximum_heap_compaction` as `clear_all_soft_refs` seems too specific. However I am not insisting on this.

Max-compaction, in Parallel full-gc, means sth rather specific -- whether some space occupied by dead objs should be replaced with filler objs and not reclaimed. It is determined by `check_maximum_compaction`.

IOW, max-compaction and soft-ref-clearing are two independent decisions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26496#discussion_r2239038714

From aboldtch at openjdk.org  Tue Jul 29 08:56:02 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 29 Jul 2025 08:56:02 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v12]
In-Reply-To: <yPHekGSU4vWQYQBhdN4a8ZTn6TLnWAkGrKbVLufzN7I=.373d8bbf-864d-4a31-8ad7-813eb7b16d39@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <yPHekGSU4vWQYQBhdN4a8ZTn6TLnWAkGrKbVLufzN7I=.373d8bbf-864d-4a31-8ad7-813eb7b16d39@github.com>
Message-ID: <bxFjg3LW9A15pCxETar6KRn4VgYwoWzBzP_tu2jfd1I=.d631d091-506e-4da2-b220-1ba44e0a9189@github.com>

On Mon, 28 Jul 2025 12:33:52 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
>> 
>> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
>> 
>> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8358586_zallocator_cleanup
>  - Make NONCOPYABLE(ZDeferredConstructed) private
>  - Add template spacing and remove extra semicolon
>  - Copyright year
>  - Move definition of ZDeferredConstructed to inline header
>  - Merge branch 'master' into JDK-8358586_zallocator_cleanup
>  - Rework ZObjectAllocator
>  - Private member variables in ZObjectAlloactorImpl
>  - Move implementation to .cpp and static-only interface in .hpp
>  - Consistent template friend style
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/19f94881...1552e399

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25693#pullrequestreview-3066331409

From aboldtch at openjdk.org  Tue Jul 29 09:40:55 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 29 Jul 2025 09:40:55 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue
In-Reply-To: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
Message-ID: <6G1IKBPAr1Dj_nN--ptlR0XfwI_Zsw9l1-B_cm09tkw=.7b92a0d0-2992-46cf-a74e-59e62e4a0d7c@github.com>

On Tue, 8 Jul 2025 13:31:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test
> gc/z/TestMappedCacheHarvest.java
> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
> 
> 
>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
> young_to_old_ratio:27561965412.478878
> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
> `uint(young_workers * young_to_old_ratio)` .
> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

Changes requested by aboldtch (Reviewer).

src/hotspot/share/gc/z/zDirector.cpp line 714:

> 712:   }
> 713: 
> 714:   double young_to_old_ratio = calculate_young_to_old_worker_ratio(stats);

I think we might as well just clamp the return value in `calculate_young_to_old_worker_ratio`. Especially since it is a local helper function which is only used here. 
```c++
  return MIN2(old_vs_young_efficiency_ratio, (double)ZOldGCThreads);

It is suppose to calculate the worker ratio. And the largest ratio we can have is ZOldGCThreads old workers to 1 young worker.

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

PR Review: https://git.openjdk.org/jdk/pull/26186#pullrequestreview-3066531759
PR Review Comment: https://git.openjdk.org/jdk/pull/26186#discussion_r2239164510

From aboldtch at openjdk.org  Tue Jul 29 09:40:56 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 29 Jul 2025 09:40:56 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue
In-Reply-To: <6G1IKBPAr1Dj_nN--ptlR0XfwI_Zsw9l1-B_cm09tkw=.7b92a0d0-2992-46cf-a74e-59e62e4a0d7c@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
 <6G1IKBPAr1Dj_nN--ptlR0XfwI_Zsw9l1-B_cm09tkw=.7b92a0d0-2992-46cf-a74e-59e62e4a0d7c@github.com>
Message-ID: <U2_FkWz75Of7hlDDDwvXsHGlLw3VgI2EYWAm1RK0Aik=.6ea0baf7-a681-4c70-bd7a-f50aaa3f942d@github.com>

On Tue, 29 Jul 2025 09:36:30 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When running the jtreg test
>> gc/z/TestMappedCacheHarvest.java
>> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
>> 
>> 
>>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> 
>> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
>> young_to_old_ratio:27561965412.478878
>> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
>> `uint(young_workers * young_to_old_ratio)` .
>> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .
>
> src/hotspot/share/gc/z/zDirector.cpp line 714:
> 
>> 712:   }
>> 713: 
>> 714:   double young_to_old_ratio = calculate_young_to_old_worker_ratio(stats);
> 
> I think we might as well just clamp the return value in `calculate_young_to_old_worker_ratio`. Especially since it is a local helper function which is only used here. 
> ```c++
>   return MIN2(old_vs_young_efficiency_ratio, (double)ZOldGCThreads);
> 
> It is suppose to calculate the worker ratio. And the largest ratio we can have is ZOldGCThreads old workers to 1 young worker.

The ratio should probably also be called `old_to_young` as it is what it actually is, not `young_to_old`. But that is a preexisting issue which we can fix in a separate rfe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26186#discussion_r2239169493

From jsikstro at openjdk.org  Tue Jul 29 10:25:06 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 10:25:06 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v12]
In-Reply-To: <bxFjg3LW9A15pCxETar6KRn4VgYwoWzBzP_tu2jfd1I=.d631d091-506e-4da2-b220-1ba44e0a9189@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <yPHekGSU4vWQYQBhdN4a8ZTn6TLnWAkGrKbVLufzN7I=.373d8bbf-864d-4a31-8ad7-813eb7b16d39@github.com>
 <bxFjg3LW9A15pCxETar6KRn4VgYwoWzBzP_tu2jfd1I=.d631d091-506e-4da2-b220-1ba44e0a9189@github.com>
Message-ID: <Zm8kJCv0BSczZyVrXEQOBzYD5oT1JXaCms7G21W_qG4=.49b7afe9-1344-4a81-b021-60bea517abc0@github.com>

On Tue, 29 Jul 2025 08:53:32 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Joel Sikstr?m 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 15 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8358586_zallocator_cleanup
>>  - Make NONCOPYABLE(ZDeferredConstructed) private
>>  - Add template spacing and remove extra semicolon
>>  - Copyright year
>>  - Move definition of ZDeferredConstructed to inline header
>>  - Merge branch 'master' into JDK-8358586_zallocator_cleanup
>>  - Rework ZObjectAllocator
>>  - Private member variables in ZObjectAlloactorImpl
>>  - Move implementation to .cpp and static-only interface in .hpp
>>  - Consistent template friend style
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/5edf1b27...1552e399
>
> Marked as reviewed by aboldtch (Reviewer).

Thank you for the reviews! @xmas92 @stefank

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

PR Comment: https://git.openjdk.org/jdk/pull/25693#issuecomment-3131768628

From jsikstro at openjdk.org  Tue Jul 29 10:25:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 10:25:07 GMT
Subject: Integrated: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <PAy3q9rShlTeBcuBRXacDF21mtqa7xDoAbkh4_eoGYc=.7f081536-a547-4cf7-9a86-b18d9e910891@github.com>

On Mon, 9 Jun 2025 11:45:00 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
> 
> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
> 
> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
> 
> Testing:
> * Oracle's tier 1-5

This pull request has now been integrated.

Changeset: 965b6810
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/965b68107ffe1c1c988d4faf6d6742629407451b
Stats:     603 lines in 14 files changed: 250 ins; 268 del; 85 mod

8358586: ZGC: Combine ZAllocator and ZObjectAllocator

Reviewed-by: aboldtch, stefank

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

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

From jsikstro at openjdk.org  Tue Jul 29 11:34:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 11:34:07 GMT
Subject: RFR: 8364248: Separate memory limit detection
Message-ID: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>

The function os::has_allocatable_memory() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.

ZGC currently uses os::has_allocatable_memory() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.

As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).

Testing:
* Oracle's tier1-2
* Manual testing on Linux by limiting the virtual address space:

$ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

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

Commit messages:
 - 8364248: Separate memory limit detection

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

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

From stuefe at openjdk.org  Tue Jul 29 12:47:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 12:47:54 GMT
Subject: RFR: 8364248: Separate memory limit detection
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <EzevJXiqD8Y0dMB4GrQCgqZtfcpedIgQ5jft0toIc0Q=.b400b571-e0e5-4f81-91e6-8ec30097e853@github.com>

On Tue, 29 Jul 2025 11:24:48 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Generally good. But why not simply return the limit. Unlimited = size_max. 

Oh, I see ZGC does that already. I would adopt that for has_limited_virtual_address_space. Then you can remove the ZGC implementation completely.

Side note, to be unbearably nitpicky, it should theoretically be "address space limit - os::vm_min_address()" since the OS does not allow low-address mappings below that.

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

PR Review: https://git.openjdk.org/jdk/pull/26530#pullrequestreview-3067358463

From mbaesken at openjdk.org  Tue Jul 29 13:07:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Jul 2025 13:07:57 GMT
Subject: RFR: 8364159: Shenandoah assertions after JDK-8361712
In-Reply-To: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>
References: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>
Message-ID: <0k4Bv1n7-fuIbNu_QeIrcnPhU1AtDYgFp74jUKoU1ak=.1b6cb56f-d337-48f0-897c-0e409625f5d7@github.com>

On Mon, 28 Jul 2025 16:49:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `ShenandoahAsserts::extract_klass_safely`, we attempt to carefully extract the Klass for an object and trip over our own feet doing this. We load the Markword twice: once to read "is_marked" and get the forwardee, once to extract the narrowKlass.
> 
> If between the first and the second load we did evacuate the object concurrently, this happens:
> 
> T1 : fwd = SheandoahForwarding::get_forwardee_raw_unchecked(obj)  => obj unmarked => (fwd == obj)
> T2 : (installs forwarding pointer in obj)
> T1: read markword from fwd again, (fwd == obj) => reads markword from forwarded obj, interprets the zeros in the upper part of the forwardee address as narrowKlass == 0, asserts
> 
> The solution is - as ShenandoahForwarding::klass() already does - to load the MW from original obj only once. Patch does that.

Thanks for fixing this, I checked for similar code locations but could not find any (hope I did not overlook something).
The fix fixes our various asserts we saw across jtreg HS tests when enabling CompressedObjectHeaders by default,

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26513#pullrequestreview-3067464337

From jsikstro at openjdk.org  Tue Jul 29 13:14:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 13:14:55 GMT
Subject: RFR: 8364248: Separate memory limit detection
In-Reply-To: <EzevJXiqD8Y0dMB4GrQCgqZtfcpedIgQ5jft0toIc0Q=.b400b571-e0e5-4f81-91e6-8ec30097e853@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <EzevJXiqD8Y0dMB4GrQCgqZtfcpedIgQ5jft0toIc0Q=.b400b571-e0e5-4f81-91e6-8ec30097e853@github.com>
Message-ID: <GeN5zUHFvxj6vW9KQIHGIvVb24v7gZ1qY0WJuQXAWzE=.70e2b200-26ad-4332-bd41-141b6cadea9e@github.com>

On Tue, 29 Jul 2025 12:44:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Generally good. But why not simply return the limit. Unlimited = size_max.
> 
> Oh, I see ZGC does that already. I would adopt that for has_limited_virtual_address_space. Then you can remove the ZGC implementation completely.

This would make the ZGC could read more nicely I think. I like it!

> Side note, to be unbearably nitpicky, it should theoretically be "address space limit - os::vm_min_address()" since the OS does not allow low-address mappings below that.

Do you think it would be prudent to add this now? To clarify, if there is a limit on POSIX, return `(size_t)rlim.rlim_cur - vm_min_address()`?

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132483693

From jsikstro at openjdk.org  Tue Jul 29 13:34:51 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 13:34:51 GMT
Subject: RFR: 8364248: Separate memory limit detection [v2]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <5h8I8ktWP7Wm8QmTu7iNRl2rSc699WEjTswu5FLEv_k=.0a89523f-5c06-4117-8d44-8760835157d4@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Rename to os::address_space_limit() and return limit only, no boolean

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/05d6b351..4c86e1b2

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

  Stats: 24 lines in 4 files changed: 1 ins; 12 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26530/head:pull/26530

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

From jsikstro at openjdk.org  Tue Jul 29 13:42:40 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 13:42:40 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/4c86e1b2..c4f27529

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

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

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

From stuefe at openjdk.org  Tue Jul 29 13:42:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 13:42:40 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <GeN5zUHFvxj6vW9KQIHGIvVb24v7gZ1qY0WJuQXAWzE=.70e2b200-26ad-4332-bd41-141b6cadea9e@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <EzevJXiqD8Y0dMB4GrQCgqZtfcpedIgQ5jft0toIc0Q=.b400b571-e0e5-4f81-91e6-8ec30097e853@github.com>
 <GeN5zUHFvxj6vW9KQIHGIvVb24v7gZ1qY0WJuQXAWzE=.70e2b200-26ad-4332-bd41-141b6cadea9e@github.com>
Message-ID: <cOSJzA2lGOizrqiJffQkuu1QXQzeFeuZXcxRaQyXZkk=.63855b14-8d46-4e30-aeca-e24801e77afc@github.com>

On Tue, 29 Jul 2025 13:12:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> > Generally good. But why not simply return the limit. Unlimited = size_max.
> > Oh, I see ZGC does that already. I would adopt that for has_limited_virtual_address_space. Then you can remove the ZGC implementation completely.
> 
> This would make the ZGC could read more nicely I think. I like it!
> 
> > Side note, to be unbearably nitpicky, it should theoretically be "address space limit - os::vm_min_address()" since the OS does not allow low-address mappings below that.
> 
> Do you think it would be prudent to add this now? To clarify, if there is a limit on POSIX, return `(size_t)rlim.rlim_cur - vm_min_address()`?

Nah, this was a half joke tbh. I don't think this fidelity is needed, and it may confuse people if we get a weirdly unaligned size back. E.g. if on Linux, the min map is configured to be just one page, you could get something like "4PB - 4K".

Also, you won't ever be able to use the full extend of that size anyway, since of course it is pre-populated with all kind of mappings, is fragmented, etc.

Side note, it would be valuable to have a sister function to os::vm_min_address() that returns the maximum mappable user address. I did hard code values at various places, but I believe ZGC has some function like this that is more elegant and more truthful. Would be nice to have this in os space.

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132578396

From jsikstro at openjdk.org  Tue Jul 29 13:42:40 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 13:42:40 GMT
Subject: RFR: 8364248: Separate memory limit detection [v2]
In-Reply-To: <5h8I8ktWP7Wm8QmTu7iNRl2rSc699WEjTswu5FLEv_k=.0a89523f-5c06-4117-8d44-8760835157d4@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <5h8I8ktWP7Wm8QmTu7iNRl2rSc699WEjTswu5FLEv_k=.0a89523f-5c06-4117-8d44-8760835157d4@github.com>
Message-ID: <UrLtb8tbBT-Nfy9zB9EbMFIGGOiU8HPn8JDEyCzlBMI=.c01dbc43-45f7-4584-8e79-ea7861f547f0@github.com>

On Tue, 29 Jul 2025 13:34:51 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename to os::address_space_limit() and return limit only, no boolean

@stefank suggested to rename has_allocatable_memory_limit() to allocatable_memory_limit() while we're on this. This is in line with what @toxaart is doing for multiple os:: functions in https://github.com/openjdk/jdk/pull/25450.

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132587277

From stuefe at openjdk.org  Tue Jul 29 13:48:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 13:48:53 GMT
Subject: RFR: 8364159: Shenandoah assertions after JDK-8361712
In-Reply-To: <0k4Bv1n7-fuIbNu_QeIrcnPhU1AtDYgFp74jUKoU1ak=.1b6cb56f-d337-48f0-897c-0e409625f5d7@github.com>
References: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>
 <0k4Bv1n7-fuIbNu_QeIrcnPhU1AtDYgFp74jUKoU1ak=.1b6cb56f-d337-48f0-897c-0e409625f5d7@github.com>
Message-ID: <iJPx42vMSogZWAyMVl58MliWNESyoGI9_ZB1APOGq2w=.79b34ff5-a219-4808-8e4d-15c7702d2ed0@github.com>

On Tue, 29 Jul 2025 13:05:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In `ShenandoahAsserts::extract_klass_safely`, we attempt to carefully extract the Klass for an object and trip over our own feet doing this. We load the Markword twice: once to read "is_marked" and get the forwardee, once to extract the narrowKlass.
>> 
>> If between the first and the second load we did evacuate the object concurrently, this happens:
>> 
>> T1 : fwd = SheandoahForwarding::get_forwardee_raw_unchecked(obj)  => obj unmarked => (fwd == obj)
>> T2 : (installs forwarding pointer in obj)
>> T1: read markword from fwd again, (fwd == obj) => reads markword from forwarded obj, interprets the zeros in the upper part of the forwardee address as narrowKlass == 0, asserts
>> 
>> The solution is - as ShenandoahForwarding::klass() already does - to load the MW from original obj only once. Patch does that.
>
> Thanks for fixing this, I checked for similar code locations but could not find any (hope I did not overlook something).
> The fix fixes our various asserts we saw across jtreg HS tests when enabling CompressedObjectHeaders by default,

Thanks @MBaesken ! My own tests are also clean now. 

Any shenandoah devs willing to give me a quick review?

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

PR Comment: https://git.openjdk.org/jdk/pull/26513#issuecomment-3132612591

From jsikstro at openjdk.org  Tue Jul 29 13:56:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 13:56:07 GMT
Subject: RFR: 8364282: ZGC: Improve ZPageAllocation JFR event sending
Message-ID: <Rg1gObksjMWKjwjuwdo5i9tO19WBk1g1ucEq5SKUeWw=.bc0d8618-9ba2-4350-8dce-adda0fb88e70@github.com>

Hello,

This is a follow up to [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), improving on how the ZPageAllocation JFR event is sent. 

The starting time for the event is measured separately from creating a local event varaible (EventZPageAllocation). This means it is better to use the anonymous EventZPageAllocation::commit rather than creating an event and sending that event, which would record the starting time again, unnecessarily.

Additionally, if the event is not enabled (either specifically or if JFR is disabled), we should not waste time sampling statistics for the event.

Testing:
* Oracle's tier1-4

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

Commit messages:
 - 8364282: ZGC: Improve ZPageAllocation JFR event sending

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

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

From stefank at openjdk.org  Tue Jul 29 14:03:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Jul 2025 14:03:54 GMT
Subject: RFR: 8364282: ZGC: Improve ZPageAllocation JFR event sending
In-Reply-To: <Rg1gObksjMWKjwjuwdo5i9tO19WBk1g1ucEq5SKUeWw=.bc0d8618-9ba2-4350-8dce-adda0fb88e70@github.com>
References: <Rg1gObksjMWKjwjuwdo5i9tO19WBk1g1ucEq5SKUeWw=.bc0d8618-9ba2-4350-8dce-adda0fb88e70@github.com>
Message-ID: <pUxOlBYRDJUoS-sk-SkTD0w1yHgOpYjLMboWWykkTtc=.ae8fc5db-8108-4168-85d7-cf862336e63b@github.com>

On Tue, 29 Jul 2025 13:51:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This is a follow up to [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), improving on how the ZPageAllocation JFR event is sent. 
> 
> The starting time for the event is measured separately from creating a local event varaible (EventZPageAllocation). This means it is better to use the anonymous EventZPageAllocation::commit rather than creating an event and sending that event, which would record the starting time again, unnecessarily.
> 
> Additionally, if the event is not enabled (either specifically or if JFR is disabled), we should not waste time sampling statistics for the event.
> 
> Testing:
> * Oracle's tier1-4

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26534#pullrequestreview-3067716485

From stuefe at openjdk.org  Tue Jul 29 14:09:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 14:09:55 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
Message-ID: <-bN2Wn_RhD_qTDG6sVzQoyPG5_ncVet_WdPC5So-w7w=.8202558b-e465-42ca-9878-500b3a868a5a@github.com>

On Tue, 29 Jul 2025 13:42:40 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()

I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.

"allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size. 

For example, how much you can *commit* depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.

I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132713524

From jsikstro at openjdk.org  Tue Jul 29 14:32:54 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 14:32:54 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
Message-ID: <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>

On Tue, 29 Jul 2025 13:42:40 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()

Just want to start of by saying thank you for taking the time with this.

> I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
> 
> "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
> 
> For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
> 
> I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.

I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.

On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132826631

From stefank at openjdk.org  Tue Jul 29 14:38:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Jul 2025 14:38:57 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
Message-ID: <7A5dxzkgMGySA-ymfuhmhF6dqKpVvxFGt9ypRdJMfCs=.f62fc5ad-86e7-47e3-989a-c98e34f902d3@github.com>

On Tue, 29 Jul 2025 13:42:40 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()

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

> 736:   // On POSIX systems, the amount of allocatable memory is limited by the
> 737:   // size of the virtual address space.
> 738:   *limit = address_space_limit();

In @toxaart's PR the out parameter is never set if the return value is false. I think the reason why that was done was so that code could be written like this:

size_t value = 0;
if (os::memory_function(value)) {
  // Succeeded - do stuff
} else {
  // Failed - do other stuff
}

// Use 0 if the function returned an error
use(value);


I think we should strive for unification around that in the various os:: memory functions. I also think that he used `&` in his patch and this function uses a pointer with the output parameter. Unification around would be good as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2240073711

From tschatzl at openjdk.org  Tue Jul 29 14:50:10 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Jul 2025 14:50:10 GMT
Subject: RFR: 8156755: [TESTBUG] Fix
 gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java
Message-ID: <BYuQJyTziEV_O4DawKEpouhMI_2-kSwbMxtRkXCy3Gg=.e3b324b0-7f04-455e-9419-cabd2a59a14b@github.com>

Hi all,

  please review this fix for this test: since it has been broken for ~9 years since right after its commit, I want to just remove it.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8156755

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

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

From ayang at openjdk.org  Tue Jul 29 14:53:54 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 29 Jul 2025 14:53:54 GMT
Subject: RFR: 8156755: [TESTBUG] Fix
 gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java
In-Reply-To: <BYuQJyTziEV_O4DawKEpouhMI_2-kSwbMxtRkXCy3Gg=.e3b324b0-7f04-455e-9419-cabd2a59a14b@github.com>
References: <BYuQJyTziEV_O4DawKEpouhMI_2-kSwbMxtRkXCy3Gg=.e3b324b0-7f04-455e-9419-cabd2a59a14b@github.com>
Message-ID: <2TXzsKMUa9hS2Ex0Rl6prQ0FK17J_RMWJNTWv-ViOT8=.53680d3a-7f07-444d-b4de-80341e33ff4d@github.com>

On Tue, 29 Jul 2025 14:44:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix for this test: since it has been broken for ~9 years since right after its commit, I want to just remove it.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26535#pullrequestreview-3067962198

From aboldtch at openjdk.org  Tue Jul 29 15:03:29 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 29 Jul 2025 15:03:29 GMT
Subject: RFR: 8361897: gc/z/TestUncommit.java fails with Uncommitted too slow
Message-ID: <HzQi0kdL2Ru747teDdaqfC7I8B_QX0ygPsv5Irr7xxk=.2b9ece78-2ed4-4ba2-b3c7-d7862017fcbb@github.com>

This proposed change loosens the the threshold for flagging slow un-committing as an error in TestUncommit.java. Rather than requiring the un-committing be completed within 3 ZUncommitDelay, allow up to 5 ZUncommitDelay to accommodate the test being executed in environments where external factors affect whether un-committing is run as expected. 

In the observed intermittent failures, what can be seen is that the un-committer thread wakes up a significant time after the expected timeout has expired. And because we expect multiple timeouts, the accumulated extra time waiting can push the actual delay just past 3 ZUncommitDelay. Using a factor of 5 instead should remove all but the most extreme intermittent occurrences and still capture if the un-commit logic breaks completely.

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

Commit messages:
 - 8361897: gc/z/TestUncommit.java fails with Uncommitted too slow

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

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

From stuefe at openjdk.org  Tue Jul 29 15:38:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 15:38:57 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
Message-ID: <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>

On Tue, 29 Jul 2025 14:29:54 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Just want to start of by saying thank you for taking the time with this.
> 
> > I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
> > "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
> > For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
> > I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.
> 
> I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.
> 
> On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.

Maybe it depends on what you need and what question it should answer. Which I don't know. If the question is "what do you think I could allocate at most, were I to try now?"), then yes, allocatableMemory would be  good name. It will always be a guess anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3133066781

From stefank at openjdk.org  Tue Jul 29 17:51:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Jul 2025 17:51:55 GMT
Subject: RFR: 8361897: gc/z/TestUncommit.java fails with Uncommitted too
 slow
In-Reply-To: <HzQi0kdL2Ru747teDdaqfC7I8B_QX0ygPsv5Irr7xxk=.2b9ece78-2ed4-4ba2-b3c7-d7862017fcbb@github.com>
References: <HzQi0kdL2Ru747teDdaqfC7I8B_QX0ygPsv5Irr7xxk=.2b9ece78-2ed4-4ba2-b3c7-d7862017fcbb@github.com>
Message-ID: <JTN1rc0zJiISAw5_VrCv8jeoaYVL87QeQbg4sO0vw-Y=.71a26ec8-f52f-4d88-8a3c-70e35000a871@github.com>

On Tue, 29 Jul 2025 14:58:09 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This proposed change loosens the the threshold for flagging slow un-committing as an error in TestUncommit.java. Rather than requiring the un-committing be completed within 3 ZUncommitDelay, allow up to 5 ZUncommitDelay to accommodate the test being executed in environments where external factors affect whether un-committing is run as expected. 
> 
> In the observed intermittent failures, what can be seen is that the un-committer thread wakes up a significant time after the expected timeout has expired. And because we expect multiple timeouts, the accumulated extra time waiting can push the actual delay just past 3 ZUncommitDelay. Using a factor of 5 instead should remove all but the most extreme intermittent occurrences and still capture if the un-commit logic breaks completely.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26536#pullrequestreview-3068586544

From shade at openjdk.org  Tue Jul 29 18:03:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Jul 2025 18:03:54 GMT
Subject: RFR: 8364249: G1: Fix some comments about "maximum_collection"
In-Reply-To: <iwS3YYyLMBJTQ4k6gERcdJfUEsn5tgSUpJBJjT5bomo=.12d4ad8e-dd66-47c2-ac4b-ccdcb8c9b72b@github.com>
References: <iwS3YYyLMBJTQ4k6gERcdJfUEsn5tgSUpJBJjT5bomo=.12d4ad8e-dd66-47c2-ac4b-ccdcb8c9b72b@github.com>
Message-ID: <t3yV-E_7UW9W3b-wHRtdfBsPcDIElDFpcuMV3nxZ0Y4=.20c3dcfc-d279-4c8d-9647-5417d1336547@github.com>

On Tue, 29 Jul 2025 08:16:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial comment change to have them adhere to the formal parameter specification.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Looks fine and trivial.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26526#pullrequestreview-3068619664

From sangheki at openjdk.org  Tue Jul 29 18:03:55 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Tue, 29 Jul 2025 18:03:55 GMT
Subject: RFR: 8364249: G1: Fix some comments about "maximum_collection"
In-Reply-To: <iwS3YYyLMBJTQ4k6gERcdJfUEsn5tgSUpJBJjT5bomo=.12d4ad8e-dd66-47c2-ac4b-ccdcb8c9b72b@github.com>
References: <iwS3YYyLMBJTQ4k6gERcdJfUEsn5tgSUpJBJjT5bomo=.12d4ad8e-dd66-47c2-ac4b-ccdcb8c9b72b@github.com>
Message-ID: <IbHAjBotgj37c-wobwo3BjjiFoEsBpy14iutthpTz_s=.06765c44-7e1e-44bc-ac15-a8dce4f9c03a@github.com>

On Tue, 29 Jul 2025 08:16:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial comment change to have them adhere to the formal parameter specification.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Looks good as is.
It might be better to add extra spaces at the below lines for alignment.

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

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26526#pullrequestreview-3068631400

From shade at openjdk.org  Tue Jul 29 19:03:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Jul 2025 19:03:21 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v2]
In-Reply-To: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
Message-ID: <I1leo9Fl9m9qVBys8GwEDjS1XWNYsGILqcamCvO4FD8=.d1028a11-d462-49cb-ab39-39de11245266@github.com>

> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>  - [ ] Linux x86_64 server fastdebug, `all`

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

  A bit more verification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26510/files
  - new: https://git.openjdk.org/jdk/pull/26510/files/7795c570..dcd8e3e7

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

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

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

From kdnilsen at openjdk.org  Tue Jul 29 19:48:55 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 29 Jul 2025 19:48:55 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v2]
In-Reply-To: <I1leo9Fl9m9qVBys8GwEDjS1XWNYsGILqcamCvO4FD8=.d1028a11-d462-49cb-ab39-39de11245266@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <I1leo9Fl9m9qVBys8GwEDjS1XWNYsGILqcamCvO4FD8=.d1028a11-d462-49cb-ab39-39de11245266@github.com>
Message-ID: <JZ24bCu5gjpAWPs-bE3vzfky09KZwDVpswGLcTS5quU=.e4c1d96f-5a72-4d0d-bfa1-f725130a005d@github.com>

On Tue, 29 Jul 2025 19:03:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>>  - [ ] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit more verification

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2791:

> 2789:   // Fill the tail with the filler object.
> 2790:   HeapWord* regions_end = align_up(end, ShenandoahHeapRegion::region_size_bytes());
> 2791:   if (regions_end > end) {

I believe fill_with_dummy_object() assumes regions_end - end >= min_fill_size.  If this is not true, you may need to leave the remnant within this region unfilled.  (We have special handling throughout to deal specially with remnants at ends of regions that are smaller than min_fill_size)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2240789847

From manc at openjdk.org  Tue Jul 29 20:47:56 2025
From: manc at openjdk.org (Man Cao)
Date: Tue, 29 Jul 2025 20:47:56 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <NqgFS7vAiHjkvdl4-EegARKzxPWYG5gZVq8U2D6GPjY=.dc9be643-f168-464a-a977-8da3d7f3e46e@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <vwFtDSQ8D_Mnk9nA5XvIglfXZq-OwDKCuHRxdU8h6bI=.e3884f55-1c0f-4f8b-883e-72bbae8f2a60@github.com>
 <NqgFS7vAiHjkvdl4-EegARKzxPWYG5gZVq8U2D6GPjY=.dc9be643-f168-464a-a977-8da3d7f3e46e@github.com>
Message-ID: <gunceDl-r3-IWw4w8nyk70C2z_m7T5OVlVqGzA-6MP0=.e8198891-e978-4c1f-8d72-16a66b0bbf8c@github.com>

On Mon, 28 Jul 2025 11:26:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Fwiw, G1 has both `ConcGCThreads` (for marking; 1/4th of `ParallelGCThreads`) and `ConcRefinementThreads` (for refinement; equal in count with `ParallelGCThreads`) which are active at the same time.
>> Not sure if only using `ConcGCThreads` (`ParallelGCThreads`?) is appropriate for this calculation.
>
> An alternative would be to consider concurrent cpu usage (`concurrent-cpu-usage`) as fraction of total cpu usage during the mutator phase (`total-cpu-usage-during-mutator`), and consider gc pause cpu usage as 100% total cpu usage during the pause (where `gc-pause-cpu-usage = #active processors * pause-duration`).
> 
> Ie. in total
> 
>   gc-time-ratio = (concurrent-cpu-usage + gc-pause-cpu-usage) / (total-cpu-usage-during-mutator + gc-pause-cpu-usage)
> 
> The dividend is G1 total cpu usage from end of previous GC to end of next GC, the divisor total cpu usage during the same time frame.
> 
> 
> It may be a bit problematic wrt to changing active processors but it seems preferable to guessing the number of threads used.

> Fwiw, G1 has both ConcGCThreads (for marking; 1/4th of ParallelGCThreads) and ConcRefinementThreads (for refinement; equal in count with ParallelGCThreads) which are active at the same time.
Not sure if only using ConcGCThreads (ParallelGCThreads?) is appropriate for this calculation.

As mentioned in the other comment, concurrent refinement threads typically consume very little CPU compared to concurrent mark workers, and most refinement threads are inactive most of the time. I think bloating up the divisor up to ConcRefinementThreads will undercount the wall-clock time "lost" by mutator threads due to concurrent GC.

For the other proposed approach using `(concurrent-cpu-usage + gc-pause-cpu-usage)` as dividend, it is much bigger change of behavior from the pause-time-based approach. I suspect it will suffer from the problem of fluctuating mutator CPU usage (https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14799278), due to using `total-cpu-usage-during-mutator` in divisor. Perhaps it is better to experiment separately from this PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2240983036

From tschatzl at openjdk.org  Wed Jul 30 07:48:04 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 30 Jul 2025 07:48:04 GMT
Subject: Integrated: 8364249: G1: Fix some comments about "maximum_collection"
In-Reply-To: <iwS3YYyLMBJTQ4k6gERcdJfUEsn5tgSUpJBJjT5bomo=.12d4ad8e-dd66-47c2-ac4b-ccdcb8c9b72b@github.com>
References: <iwS3YYyLMBJTQ4k6gERcdJfUEsn5tgSUpJBJjT5bomo=.12d4ad8e-dd66-47c2-ac4b-ccdcb8c9b72b@github.com>
Message-ID: <LL01nP0BBZ_0eyYaX1Kg5TQkx3vJHNquL9vETKs8Cec=.c1f55abf-15f7-4551-b2d8-3b56bd8c80ea@github.com>

On Tue, 29 Jul 2025 08:16:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial comment change to have them adhere to the formal parameter specification.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 302508df
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/302508df9ebb66f27fffcbe8496ccea95385e61a
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8364249: G1: Fix some comments about "maximum_collection"

Reviewed-by: shade, sangheki

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

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

From tschatzl at openjdk.org  Wed Jul 30 07:48:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 30 Jul 2025 07:48:03 GMT
Subject: RFR: 8364249: G1: Fix some comments about "maximum_collection"
In-Reply-To: <t3yV-E_7UW9W3b-wHRtdfBsPcDIElDFpcuMV3nxZ0Y4=.20c3dcfc-d279-4c8d-9647-5417d1336547@github.com>
References: <iwS3YYyLMBJTQ4k6gERcdJfUEsn5tgSUpJBJjT5bomo=.12d4ad8e-dd66-47c2-ac4b-ccdcb8c9b72b@github.com>
 <t3yV-E_7UW9W3b-wHRtdfBsPcDIElDFpcuMV3nxZ0Y4=.20c3dcfc-d279-4c8d-9647-5417d1336547@github.com>
Message-ID: <y6HIMXbrRDWkY1dteHcbydjp_MTPeHyOh793QYzr5dE=.93aad748-f7a1-4217-b272-1485aed82ff0@github.com>

On Tue, 29 Jul 2025 17:59:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial comment change to have them adhere to the formal parameter specification.
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Looks fine and trivial.

Thanks @shipilev @sangheon for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26526#issuecomment-3135203385

From ayang at openjdk.org  Wed Jul 30 07:54:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Jul 2025 07:54:55 GMT
Subject: RFR: 8156755: [TESTBUG] Fix
 gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java
In-Reply-To: <BYuQJyTziEV_O4DawKEpouhMI_2-kSwbMxtRkXCy3Gg=.e3b324b0-7f04-455e-9419-cabd2a59a14b@github.com>
References: <BYuQJyTziEV_O4DawKEpouhMI_2-kSwbMxtRkXCy3Gg=.e3b324b0-7f04-455e-9419-cabd2a59a14b@github.com>
Message-ID: <zDpOcF_TbYAQ8E-C9AHZCx1WSzLECoxmYbf5t55bbXg=.64b80634-e69e-4b1b-851b-eba240ae8b3e@github.com>

On Tue, 29 Jul 2025 14:44:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix for this test: since it has been broken for ~9 years since right after its commit, I want to just remove it.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/26535#issuecomment-3135228546

From ayang at openjdk.org  Wed Jul 30 08:14:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Jul 2025 08:14:03 GMT
Subject: RFR: 8364196: G1: Fix typo in "cset_groud_gid" local variable in
 G1FlushHumongousCandidateRemSets
In-Reply-To: <bFAX1eijluMYrCa7Ppd7FcI2xdwzQtH29p2rue5Gurg=.ac69c5db-d7de-4785-ac6d-9f71b294b52d@github.com>
References: <bFAX1eijluMYrCa7Ppd7FcI2xdwzQtH29p2rue5Gurg=.ac69c5db-d7de-4785-ac6d-9f71b294b52d@github.com>
Message-ID: <_34v5bxjjdHAOwqU8PtlG_ClPSR0Vahdkfeu9otw4Nk=.3bb91ff4-1fd1-41d4-8aaa-f51413b5a555@github.com>

On Mon, 28 Jul 2025 13:34:29 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to the typo "cset_groud_gid" which should mean "cset_group_id".
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/26505#issuecomment-3135227581

From tschatzl at openjdk.org  Wed Jul 30 08:14:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 30 Jul 2025 08:14:07 GMT
Subject: RFR: 8156755: [TESTBUG] Fix
 gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java
In-Reply-To: <zDpOcF_TbYAQ8E-C9AHZCx1WSzLECoxmYbf5t55bbXg=.64b80634-e69e-4b1b-851b-eba240ae8b3e@github.com>
References: <BYuQJyTziEV_O4DawKEpouhMI_2-kSwbMxtRkXCy3Gg=.e3b324b0-7f04-455e-9419-cabd2a59a14b@github.com>
 <zDpOcF_TbYAQ8E-C9AHZCx1WSzLECoxmYbf5t55bbXg=.64b80634-e69e-4b1b-851b-eba240ae8b3e@github.com>
Message-ID: <5r2KmLyg1gi6d4kEMP_Rg16KQVmVqxrft2z0fLgq0DQ=.23d812b2-d21c-41c3-a028-e235ac1ac3b9@github.com>

On Wed, 30 Jul 2025 07:52:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this fix for this test: since it has been broken for ~9 years since right after its commit, I want to just remove it.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Trivial.

Thanks @albertnetymk for your review

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

PR Comment: https://git.openjdk.org/jdk/pull/26535#issuecomment-3135279817

From tschatzl at openjdk.org  Wed Jul 30 08:14:04 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 30 Jul 2025 08:14:04 GMT
Subject: RFR: 8364196: G1: Fix typo in "cset_groud_gid" local variable in
 G1FlushHumongousCandidateRemSets
In-Reply-To: <_34v5bxjjdHAOwqU8PtlG_ClPSR0Vahdkfeu9otw4Nk=.3bb91ff4-1fd1-41d4-8aaa-f51413b5a555@github.com>
References: <bFAX1eijluMYrCa7Ppd7FcI2xdwzQtH29p2rue5Gurg=.ac69c5db-d7de-4785-ac6d-9f71b294b52d@github.com>
 <_34v5bxjjdHAOwqU8PtlG_ClPSR0Vahdkfeu9otw4Nk=.3bb91ff4-1fd1-41d4-8aaa-f51413b5a555@github.com>
Message-ID: <uWeN9ng6y9WRMCVYXBHnz4MkyvHB7ontxJZJ1jIlXOk=.784d73e0-dd9f-4e34-8f21-8718c442e5c8@github.com>

On Wed, 30 Jul 2025 07:52:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this fix to the typo "cset_groud_gid" which should mean "cset_group_id".
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Trivial.

Thanks @albertnetymk for your review

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

PR Comment: https://git.openjdk.org/jdk/pull/26505#issuecomment-3135278953

From tschatzl at openjdk.org  Wed Jul 30 08:14:08 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 30 Jul 2025 08:14:08 GMT
Subject: Integrated: 8156755: [TESTBUG] Fix
 gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java
In-Reply-To: <BYuQJyTziEV_O4DawKEpouhMI_2-kSwbMxtRkXCy3Gg=.e3b324b0-7f04-455e-9419-cabd2a59a14b@github.com>
References: <BYuQJyTziEV_O4DawKEpouhMI_2-kSwbMxtRkXCy3Gg=.e3b324b0-7f04-455e-9419-cabd2a59a14b@github.com>
Message-ID: <nnEh7BxIrfQK8SwE5LY_8Ea-46nxNyFAziBbBvGlzGk=.e59482ee-566a-4968-9359-7fa5d67e9f9e@github.com>

On Tue, 29 Jul 2025 14:44:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix for this test: since it has been broken for ~9 years since right after its commit, I want to just remove it.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 7af3cd95
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7af3cd955839f98a37b915480266ccd7be27b147
Stats:     1067 lines in 8 files changed: 0 ins; 1067 del; 0 mod

8156755: [TESTBUG] Fix gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java

Reviewed-by: ayang

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

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

From tschatzl at openjdk.org  Wed Jul 30 08:14:05 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 30 Jul 2025 08:14:05 GMT
Subject: Integrated: 8364196: G1: Fix typo in "cset_groud_gid" local variable
 in G1FlushHumongousCandidateRemSets
In-Reply-To: <bFAX1eijluMYrCa7Ppd7FcI2xdwzQtH29p2rue5Gurg=.ac69c5db-d7de-4785-ac6d-9f71b294b52d@github.com>
References: <bFAX1eijluMYrCa7Ppd7FcI2xdwzQtH29p2rue5Gurg=.ac69c5db-d7de-4785-ac6d-9f71b294b52d@github.com>
Message-ID: <7VzEVpkKBOJhlYFX_-5PUvnQcgiOPW8UXwE3MNeEV0E=.645a74cd-decf-43f2-8382-9d66c90dc551@github.com>

On Mon, 28 Jul 2025 13:34:29 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to the typo "cset_groud_gid" which should mean "cset_group_id".
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 4da1c9df
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4da1c9df52a9e36214f7aeffae26fde3dc4570bc
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8364196: G1: Fix typo in "cset_groud_gid" local variable in G1FlushHumongousCandidateRemSets

Reviewed-by: ayang

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

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

From mbaesken at openjdk.org  Wed Jul 30 08:16:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 30 Jul 2025 08:16:11 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue [v2]
In-Reply-To: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
Message-ID: <Dd2N9-77ncdBBFeU7RwvD-agPKln6MWyoCbSBZ6y36k=.68dc17fd-f2ad-4feb-a9ad-b605bceaf5c8@github.com>

> When running the jtreg test
> gc/z/TestMappedCacheHarvest.java
> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
> 
> 
>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
> young_to_old_ratio:27561965412.478878
> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
> `uint(young_workers * young_to_old_ratio)` .
> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

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

  Change suggested by xmas92

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26186/files
  - new: https://git.openjdk.org/jdk/pull/26186/files/1cdc7b9f..c4747d17

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

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

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

From stefank at openjdk.org  Wed Jul 30 08:34:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Jul 2025 08:34:55 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue [v2]
In-Reply-To: <Dd2N9-77ncdBBFeU7RwvD-agPKln6MWyoCbSBZ6y36k=.68dc17fd-f2ad-4feb-a9ad-b605bceaf5c8@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
 <Dd2N9-77ncdBBFeU7RwvD-agPKln6MWyoCbSBZ6y36k=.68dc17fd-f2ad-4feb-a9ad-b605bceaf5c8@github.com>
Message-ID: <WK4Ckn6ODwktR8KwK8LFQyqaW5WchG-g9qcX7d3sdL4=.13f48a06-730f-4caa-b4e1-b9dbef28b0cd@github.com>

On Wed, 30 Jul 2025 08:16:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the jtreg test
>> gc/z/TestMappedCacheHarvest.java
>> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
>> 
>> 
>>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> 
>> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
>> young_to_old_ratio:27561965412.478878
>> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
>> `uint(young_workers * young_to_old_ratio)` .
>> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change suggested by xmas92

src/hotspot/share/gc/z/zDirector.cpp line 714:

> 712:   }
> 713: 
> 714:   double young_to_old_ratio = calculate_young_to_old_worker_ratio(stats);

I guess this can then be reverted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26186#discussion_r2241922969

From jsikstro at openjdk.org  Wed Jul 30 09:35:50 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 09:35:50 GMT
Subject: RFR: 8364248: Separate memory limit detection [v4]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  os:: unification in allocatable_memory_limit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/c4f27529..9b9d9f7a

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

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

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

From jsikstro at openjdk.org  Wed Jul 30 09:35:52 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 09:35:52 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <7A5dxzkgMGySA-ymfuhmhF6dqKpVvxFGt9ypRdJMfCs=.f62fc5ad-86e7-47e3-989a-c98e34f902d3@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <7A5dxzkgMGySA-ymfuhmhF6dqKpVvxFGt9ypRdJMfCs=.f62fc5ad-86e7-47e3-989a-c98e34f902d3@github.com>
Message-ID: <dGZniGfA9q_X2B7_ycEfxQUyJymR1UUtxPjPpMSY6EY=.6ffc3403-bb9b-42af-8b80-ca4dff4336ea@github.com>

On Tue, 29 Jul 2025 14:34:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()
>
> src/hotspot/os/posix/os_posix.cpp line 738:
> 
>> 736:   // On POSIX systems, the amount of allocatable memory is limited by the
>> 737:   // size of the virtual address space.
>> 738:   *limit = address_space_limit();
> 
> In @toxaart's PR the out parameter is never set if the return value is false. I think the reason why that was done was so that code could be written like this:
> 
> size_t value = 0;
> if (os::memory_function(value)) {
>   // Succeeded - do stuff
> } else {
>   // Failed - do other stuff
> }
> 
> // Use 0 if the function returned an error
> use(value);
> 
> 
> I think we should strive for unification around that in the various os:: memory functions. I also think that he used `&` in his patch and this function uses a pointer with the output parameter. Unification around would be good as well.

Sounds good. I'll change to using a reference instead of a pointer and only set the out-parameter if we return true.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2242063296

From jsikstro at openjdk.org  Wed Jul 30 09:39:59 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 09:39:59 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
Message-ID: <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>

On Tue, 29 Jul 2025 15:36:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Just want to start of by saying thank you for taking the time with this.
> > > I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
> > > "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
> > > For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
> > > I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.
> > 
> > 
> > I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.
> > On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.
> 
> Maybe it depends on what you need and what question it should answer. Which I don't know. If the question is "what do you think I could allocate at most, were I to try now?"), then yes, allocatableMemory would be good name. It will always be a guess anyway.

I agree that it will always be a guess. What I believe a follow-up to this patch would do is to adjust os::allocatable_memory_limit() to take some user-configurable limit into account on Windows, like Job Objects, which is quite different from how the POSIX implementation works, so having two functions like we have now is needed in some way.

I'm open to chaning os::allocatable_memory_limit to something else, maybe something containing the word "commit", since that's what we actually care about. `os::commit_memory_limit()`?

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3135543197

From shade at openjdk.org  Wed Jul 30 09:42:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 09:42:53 GMT
Subject: RFR: 8364159: Shenandoah assertions after JDK-8361712
In-Reply-To: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>
References: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>
Message-ID: <hdjiDb3hb_7VWuq0RJxP01X7aFNKZe_H06gNSXqilxw=.9274a585-d890-4838-9c61-e96f14eb9baa@github.com>

On Mon, 28 Jul 2025 16:49:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `ShenandoahAsserts::extract_klass_safely`, we attempt to carefully extract the Klass for an object and trip over our own feet doing this. We load the Markword twice: once to read "is_marked" and get the forwardee, once to extract the narrowKlass.
> 
> If between the first and the second load we did evacuate the object concurrently, this happens:
> 
> T1 : fwd = SheandoahForwarding::get_forwardee_raw_unchecked(obj)  => obj unmarked => (fwd == obj)
> T2 : (installs forwarding pointer in obj)
> T1: read markword from fwd again, (fwd == obj) => reads markword from forwarded obj, interprets the zeros in the upper part of the forwardee address as narrowKlass == 0, asserts
> 
> The solution is - as ShenandoahForwarding::klass() already does - to load the MW from original obj only once. Patch does that.

Yes, please integrate. Seeing failure in current testing as well.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26513#pullrequestreview-3070649282

From shade at openjdk.org  Wed Jul 30 09:59:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 09:59:14 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v3]
In-Reply-To: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
Message-ID: <1S8L0L2mkUxXX22yW7rJkFNublNwQfVuPZsb9-npZ5c=.66ddc342-2d88-432e-9c8a-3d45f229f525@github.com>

> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>  - [ ] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev 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:

 - Do not fill out the entire regions
 - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
 - A bit more verification
 - Fix
 - Fix
 - Regular CDS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26510/files
  - new: https://git.openjdk.org/jdk/pull/26510/files/dcd8e3e7..1c705291

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

  Stats: 980 lines in 26 files changed: 601 ins; 293 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/26510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26510/head:pull/26510

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

From shade at openjdk.org  Wed Jul 30 09:59:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 09:59:14 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v2]
In-Reply-To: <JZ24bCu5gjpAWPs-bE3vzfky09KZwDVpswGLcTS5quU=.e4c1d96f-5a72-4d0d-bfa1-f725130a005d@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <I1leo9Fl9m9qVBys8GwEDjS1XWNYsGILqcamCvO4FD8=.d1028a11-d462-49cb-ab39-39de11245266@github.com>
 <JZ24bCu5gjpAWPs-bE3vzfky09KZwDVpswGLcTS5quU=.e4c1d96f-5a72-4d0d-bfa1-f725130a005d@github.com>
Message-ID: <ytAeOVxHHNog6lKn59RbtCMAiMEAoDiJtWDmQeDENdk=.86b25d8c-3989-4198-88f7-3333be8b212c@github.com>

On Tue, 29 Jul 2025 19:46:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   A bit more verification
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2791:
> 
>> 2789:   // Fill the tail with the filler object.
>> 2790:   HeapWord* regions_end = align_up(end, ShenandoahHeapRegion::region_size_bytes());
>> 2791:   if (regions_end > end) {
> 
> I believe fill_with_dummy_object() assumes regions_end - end >= min_fill_size.  If this is not true, you may need to leave the remnant within this region unfilled.  (We have special handling throughout to deal specially with remnants at ends of regions that are smaller than min_fill_size)

Right. Grrr. Let's scrap the filler object idea then, and just ask freeset to deal with the trailing (non-full) region itself. Done in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2242129865

From stuefe at openjdk.org  Wed Jul 30 10:15:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 30 Jul 2025 10:15:00 GMT
Subject: Integrated: 8364159: Shenandoah assertions after JDK-8361712
In-Reply-To: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>
References: <cb5cFUGDXdUkP6UOQt6uuOWeNIj4gN6rYXPrleBu1t0=.bc27f79b-2948-47f6-9a64-6291e2defb74@github.com>
Message-ID: <vccjgQCCZBlNn25txIO5RDY6qVNcD9uZMx05FEWDSUc=.bc1fa217-157b-4232-81f0-d35827797c6b@github.com>

On Mon, 28 Jul 2025 16:49:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `ShenandoahAsserts::extract_klass_safely`, we attempt to carefully extract the Klass for an object and trip over our own feet doing this. We load the Markword twice: once to read "is_marked" and get the forwardee, once to extract the narrowKlass.
> 
> If between the first and the second load we did evacuate the object concurrently, this happens:
> 
> T1 : fwd = SheandoahForwarding::get_forwardee_raw_unchecked(obj)  => obj unmarked => (fwd == obj)
> T2 : (installs forwarding pointer in obj)
> T1: read markword from fwd again, (fwd == obj) => reads markword from forwarded obj, interprets the zeros in the upper part of the forwardee address as narrowKlass == 0, asserts
> 
> The solution is - as ShenandoahForwarding::klass() already does - to load the MW from original obj only once. Patch does that.

This pull request has now been integrated.

Changeset: 317dacc3
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/317dacc308993d534aeba397d0550ad056fe595b
Stats:     8 lines in 1 file changed: 4 ins; 0 del; 4 mod

8364159: Shenandoah assertions after JDK-8361712

Reviewed-by: mbaesken, shade

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

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

From shade at openjdk.org  Wed Jul 30 10:22:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 10:22:14 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v4]
In-Reply-To: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
Message-ID: <gNnSD9XLsfZBLVS8tFo0c2uPQ1yEILG2EImzWgDmGm0=.a85fd08a-3d88-4cad-94bb-7dfd5d02225f@github.com>

> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>  - [ ] Linux x86_64 server fastdebug, `all`

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

 - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
 - Do not fill out the entire regions
 - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
 - A bit more verification
 - Fix
 - Fix
 - Regular CDS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26510/files
  - new: https://git.openjdk.org/jdk/pull/26510/files/1c705291..84a64649

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

  Stats: 2817 lines in 130 files changed: 978 ins; 1616 del; 223 mod
  Patch: https://git.openjdk.org/jdk/pull/26510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26510/head:pull/26510

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

From jsikstro at openjdk.org  Wed Jul 30 11:28:53 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 11:28:53 GMT
Subject: RFR: 8361897: gc/z/TestUncommit.java fails with Uncommitted too
 slow
In-Reply-To: <HzQi0kdL2Ru747teDdaqfC7I8B_QX0ygPsv5Irr7xxk=.2b9ece78-2ed4-4ba2-b3c7-d7862017fcbb@github.com>
References: <HzQi0kdL2Ru747teDdaqfC7I8B_QX0ygPsv5Irr7xxk=.2b9ece78-2ed4-4ba2-b3c7-d7862017fcbb@github.com>
Message-ID: <-kOOClnNLhLIgGGuXhCoBHmTa-OzVjPbSumTgAz5FMA=.d25fa47e-e25f-4769-8705-80395f6c8859@github.com>

On Tue, 29 Jul 2025 14:58:09 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This proposed change loosens the the threshold for flagging slow un-committing as an error in TestUncommit.java. Rather than requiring the un-committing be completed within 3 ZUncommitDelay, allow up to 5 ZUncommitDelay to accommodate the test being executed in environments where external factors affect whether un-committing is run as expected. 
> 
> In the observed intermittent failures, what can be seen is that the un-committer thread wakes up a significant time after the expected timeout has expired. And because we expect multiple timeouts, the accumulated extra time waiting can push the actual delay just past 3 ZUncommitDelay. Using a factor of 5 instead should remove all but the most extreme intermittent occurrences and still capture if the un-commit logic breaks completely.

Looks good.

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

Marked as reviewed by jsikstro (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26536#pullrequestreview-3070976280

From aboldtch at openjdk.org  Wed Jul 30 11:30:55 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 30 Jul 2025 11:30:55 GMT
Subject: RFR: 8364282: ZGC: Improve ZPageAllocation JFR event sending
In-Reply-To: <Rg1gObksjMWKjwjuwdo5i9tO19WBk1g1ucEq5SKUeWw=.bc0d8618-9ba2-4350-8dce-adda0fb88e70@github.com>
References: <Rg1gObksjMWKjwjuwdo5i9tO19WBk1g1ucEq5SKUeWw=.bc0d8618-9ba2-4350-8dce-adda0fb88e70@github.com>
Message-ID: <oU7Bec-dnuoJPdqzNGYVMcr2uA2mDrlySGktnc9B09E=.a754629d-08b6-4ec9-b509-e662a2a80ddc@github.com>

On Tue, 29 Jul 2025 13:51:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This is a follow up to [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), improving on how the ZPageAllocation JFR event is sent. 
> 
> The starting time for the event is measured separately from creating a local event varaible (EventZPageAllocation). This means it is better to use the anonymous EventZPageAllocation::commit rather than creating an event and sending that event, which would record the starting time again, unnecessarily.
> 
> Additionally, if the event is not enabled (either specifically or if JFR is disabled), we should not waste time sampling statistics for the event.
> 
> Testing:
> * Oracle's tier1-4

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26534#pullrequestreview-3070982111

From mbaesken at openjdk.org  Wed Jul 30 11:37:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 30 Jul 2025 11:37:29 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue [v3]
In-Reply-To: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
Message-ID: <O6nUKWk5ABRRIbJxy72BNL7KNBmy4Vgf-LIL6l7vB9M=.a831cb47-e734-48b8-854c-08c38431ae44@github.com>

> When running the jtreg test
> gc/z/TestMappedCacheHarvest.java
> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
> 
> 
>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
> young_to_old_ratio:27561965412.478878
> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
> `uint(young_workers * young_to_old_ratio)` .
> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

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

  Bring back const

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26186/files
  - new: https://git.openjdk.org/jdk/pull/26186/files/c4747d17..ca56e7bf

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

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

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

From aboldtch at openjdk.org  Wed Jul 30 11:42:56 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 30 Jul 2025 11:42:56 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue [v3]
In-Reply-To: <O6nUKWk5ABRRIbJxy72BNL7KNBmy4Vgf-LIL6l7vB9M=.a831cb47-e734-48b8-854c-08c38431ae44@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
 <O6nUKWk5ABRRIbJxy72BNL7KNBmy4Vgf-LIL6l7vB9M=.a831cb47-e734-48b8-854c-08c38431ae44@github.com>
Message-ID: <1pUroCFjOakkqSNSq4NHBnupPRmD3knn2ylXlrOaxb0=.fa84e284-4ad0-4789-b854-577746a7ef03@github.com>

On Wed, 30 Jul 2025 11:37:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the jtreg test
>> gc/z/TestMappedCacheHarvest.java
>> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
>> 
>> 
>>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> 
>> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
>> young_to_old_ratio:27561965412.478878
>> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
>> `uint(young_workers * young_to_old_ratio)` .
>> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back const

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26186#pullrequestreview-3071015633

From jsikstro at openjdk.org  Wed Jul 30 12:21:05 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 12:21:05 GMT
Subject: RFR: 8364351: ZGC: Replace usages of ZPageRange() with
 ZPageAgeRangeAll
Message-ID: <zVtMciO3XDntgD9F_b9TouGQzugRMp7YYEl9GDHE4D8=.80880a0d-ed53-4415-9e29-5c8271a29f74@github.com>

Hello,

Following up on [JDK-8357053](https://bugs.openjdk.org/browse/JDK-8357053) and [JDK-8358586](https://bugs.openjdk.org/browse/JDK-8358586), this RFE adds a new pre-defined ZPageAge iterator called ZPageAgeRangeAll to iterate over all ages. ZPageAgeRangeAll replaces the usage of `ZPageAgeRange()`, and the ZPageAge gtest is expanded to cover this.

Testing:
* Oracle's tier 1-4

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

Commit messages:
 - 8364351: ZGC: Replace usages of ZPageRange() with ZPageAgeRangeAll

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

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

From tschatzl at openjdk.org  Wed Jul 30 12:21:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 30 Jul 2025 12:21:58 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <gunceDl-r3-IWw4w8nyk70C2z_m7T5OVlVqGzA-6MP0=.e8198891-e978-4c1f-8d72-16a66b0bbf8c@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <vwFtDSQ8D_Mnk9nA5XvIglfXZq-OwDKCuHRxdU8h6bI=.e3884f55-1c0f-4f8b-883e-72bbae8f2a60@github.com>
 <NqgFS7vAiHjkvdl4-EegARKzxPWYG5gZVq8U2D6GPjY=.dc9be643-f168-464a-a977-8da3d7f3e46e@github.com>
 <gunceDl-r3-IWw4w8nyk70C2z_m7T5OVlVqGzA-6MP0=.e8198891-e978-4c1f-8d72-16a66b0bbf8c@github.com>
Message-ID: <8FCHTMjSXHFLs5Q8jw9gLgWS-t1jCpRsSPKhR5LCUBE=.d845e003-ba02-47b9-afe2-45309f9adbae@github.com>

On Tue, 29 Jul 2025 20:45:36 GMT, Man Cao <manc at openjdk.org> wrote:

> As mentioned in the other comment, concurrent refinement threads typically consume very little CPU compared to concurrent mark workers, and most refinement threads are inactive most of the time. I think bloating up the divisor up to ConcRefinementThreads will undercount the wall-clock time "lost" by mutator threads due to concurrent GC.

What if there is significant concurrent refinement activity? That would unnecessarily expand the heap.

Running one of my go-to benchmarks (some "object storage"; you would not want to run it at that gc cpu usage level, i.e. 55% ;) ) gives the following thread times:

sun.threads.cpu_time.gc_conc_mark=       187537964718
sun.threads.cpu_time.gc_conc_refine=    1306781191282
sun.threads.cpu_time.gc_parallel_workers=561790592662
sun.threads.cpu_time.gc_service=            125919008

Not a very realistic scenario, still I would prefer to not discount refinement costs...

Maybe somehow separate marking and refinment cpu activity and merge again?

> For the other proposed approach using (concurrent-cpu-usage + gc-pause-cpu-usage) as dividend, it is much bigger change of behavior from the pause-time-based approach. I suspect it will suffer from the problem of fluctuating mutator CPU usage (https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14799278), due to using total-cpu-usage-during-mutator in divisor. Perhaps it is better to experiment separately from this PR?

It is a combination of both: for pauses use the existing approach, for mutator time it uses cpu usage.

However I agree that probably it suffers from the same issue, weighing cpu usage too much if the mutator is mostly idle, causing overexpansion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2242459016

From mbaesken at openjdk.org  Wed Jul 30 12:31:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 30 Jul 2025 12:31:02 GMT
Subject: RFR: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue [v3]
In-Reply-To: <O6nUKWk5ABRRIbJxy72BNL7KNBmy4Vgf-LIL6l7vB9M=.a831cb47-e734-48b8-854c-08c38431ae44@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
 <O6nUKWk5ABRRIbJxy72BNL7KNBmy4Vgf-LIL6l7vB9M=.a831cb47-e734-48b8-854c-08c38431ae44@github.com>
Message-ID: <5gc1VXWJw5ymUTGmPrd1-ZhmHGdcJ3aIno3gdebgDYU=.a6b9d8ed-87ff-4e59-b1cb-1706ba33b5e3@github.com>

On Wed, 30 Jul 2025 11:37:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the jtreg test
>> gc/z/TestMappedCacheHarvest.java
>> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
>> 
>> 
>>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> 
>> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
>> young_to_old_ratio:27561965412.478878
>> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
>> `uint(young_workers * young_to_old_ratio)` .
>> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back const

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26186#issuecomment-3136082977

From mbaesken at openjdk.org  Wed Jul 30 12:31:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 30 Jul 2025 12:31:03 GMT
Subject: Integrated: 8360817: [ubsan] zDirector select_worker_threads - outside
 the range of representable values issue
In-Reply-To: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
References: <MLKTHMNZE3w8SfCp7yKvmRqVslyFCowemlx_CoYh1kg=.b5239fdd-0e69-48c4-8f4c-28268d005256@github.com>
Message-ID: <0-Bc02DaKCbJAtvwgWVjdf5wU6VWsq8VOFfy7ANM_Xk=.f315030e-f130-4385-9da8-32e3fbfbb240@github.com>

On Tue, 8 Jul 2025 13:31:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test
> gc/z/TestMappedCacheHarvest.java
> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
> 
> 
>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
> young_to_old_ratio:27561965412.478878
> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
> `uint(young_workers * young_to_old_ratio)` .
> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

This pull request has now been integrated.

Changeset: 16da81eb
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16da81eb439e48459e4ca19d6f97c0de5e2d2398
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8360817: [ubsan] zDirector select_worker_threads - outside the range of representable values issue

Reviewed-by: aboldtch, lucy

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

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

From ayang at openjdk.org  Wed Jul 30 13:49:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Jul 2025 13:49:55 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v3]
In-Reply-To: <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
 <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
Message-ID: <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>

On Wed, 30 Jul 2025 09:37:08 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit...

Based on this description, I'd think `commit_memory_limit` is more accurate in what this function returns. Taking a step further, I'd suggest `reserve_memory_limit` for `address_space_limit`; then it's obvious that they are semantically related and can be placed next to each other.

> to rename has_allocatable_memory_limit() to allocatable_memory_limit()...

I think PR25450 use bool-return to indicate error-or-not, which is quite diff here. Alternatively, is it possible to change the signature to `size_t x_limit(void)`, returning `size_max` when there is no limit? (Is there a semantic difference btw has-limit-at-size-max and no-limit?)

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3136433057

From stefank at openjdk.org  Wed Jul 30 15:01:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Jul 2025 15:01:56 GMT
Subject: RFR: 8364351: ZGC: Replace usages of ZPageAgeRange() with
 ZPageAgeRangeAll
In-Reply-To: <zVtMciO3XDntgD9F_b9TouGQzugRMp7YYEl9GDHE4D8=.80880a0d-ed53-4415-9e29-5c8271a29f74@github.com>
References: <zVtMciO3XDntgD9F_b9TouGQzugRMp7YYEl9GDHE4D8=.80880a0d-ed53-4415-9e29-5c8271a29f74@github.com>
Message-ID: <tYObFjjipcyNjwwHbNCDt8rBFRWoxx9O5DwrKN6d1ds=.14d76e6c-d643-4dae-adce-6b150a0b9be2@github.com>

On Wed, 30 Jul 2025 12:15:34 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> Following up on [JDK-8357053](https://bugs.openjdk.org/browse/JDK-8357053) and [JDK-8358586](https://bugs.openjdk.org/browse/JDK-8358586), this RFE adds a new pre-defined ZPageAge iterator called ZPageAgeRangeAll to iterate over all ages. ZPageAgeRangeAll replaces the usage of `ZPageAgeRange()`, and the ZPageAge gtest is expanded to cover this.
> 
> Testing:
> * Oracle's tier 1-4

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26549#pullrequestreview-3072057335

From manc at openjdk.org  Wed Jul 30 20:50:56 2025
From: manc at openjdk.org (Man Cao)
Date: Wed, 30 Jul 2025 20:50:56 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <8FCHTMjSXHFLs5Q8jw9gLgWS-t1jCpRsSPKhR5LCUBE=.d845e003-ba02-47b9-afe2-45309f9adbae@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <vwFtDSQ8D_Mnk9nA5XvIglfXZq-OwDKCuHRxdU8h6bI=.e3884f55-1c0f-4f8b-883e-72bbae8f2a60@github.com>
 <NqgFS7vAiHjkvdl4-EegARKzxPWYG5gZVq8U2D6GPjY=.dc9be643-f168-464a-a977-8da3d7f3e46e@github.com>
 <gunceDl-r3-IWw4w8nyk70C2z_m7T5OVlVqGzA-6MP0=.e8198891-e978-4c1f-8d72-16a66b0bbf8c@github.com>
 <8FCHTMjSXHFLs5Q8jw9gLgWS-t1jCpRsSPKhR5LCUBE=.d845e003-ba02-47b9-afe2-45309f9adbae@github.com>
Message-ID: <IoDFQJRMGj-BGkYfvV4oh6IX0co45GCDPFOgaG-YO8E=.e5502e57-b5ec-4812-969f-89a791400042@github.com>

On Wed, 30 Jul 2025 12:19:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Not a very realistic scenario, still I would prefer to not discount refinement costs...
> Maybe somehow separate marking and refinment cpu activity and merge again?

Fair enough. Perhaps we need to implement a metric that estimates how many refinement threads are active on average, between two pauses? So we don't overcount or undercount refinement cost.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2243827378

From duke at openjdk.org  Wed Jul 30 22:26:01 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Jul 2025 22:26:01 GMT
Subject: Withdrawn: 8357533: ZGC: ZIndexDistributorClaimTree functions not
 inlined on Windows
In-Reply-To: <XeJkFPL45Aixq3YzlJjsQrNR_l2OmKew53Tw1tgyY6M=.76a49afc-c1ad-4fa5-9141-dea321a2d705@github.com>
References: <XeJkFPL45Aixq3YzlJjsQrNR_l2OmKew53Tw1tgyY6M=.76a49afc-c1ad-4fa5-9141-dea321a2d705@github.com>
Message-ID: <6HjkwpQ2URag0Jb2GTqVqESAERisM0aomIfXWMvSZgM=.b6ead055-14c1-4f64-9eb1-8437fa4b5734@github.com>

On Thu, 22 May 2025 08:07:36 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> While investigating a minor performance regression in a System.gc() microbenchmark I saw that the Concurrent Remap Roots phase took a significant portion of the GC cycle time.
> 
> It turns out that even though we use constexpr we don't get the inlining of the the functions as we expected and this results in a noticeable performance loss.
> 
> When running System.gc() with on old GC worker thread with a 16TB max heap size we spend around 300 ms just iterating over the page table and its indices via ZIndexDistributorClaimTree. If the inlining is fixed this drops down to ~70 ms, which is similar to what we see on Linux and MacOS.
> 
> We already have a patch out to remove the last usage of the ZIndexDistributor mechanism in https://github.com/openjdk/jdk/pull/25345, but ZIndexDistributor has less restrictions and is easier to use so we might want to keep it around (with fixed performance) so that it can be used for prototyping and maybe future features.
> 
> Noteworthy in the patch is the following function:
> 
>   static constexpr int level_multiplier(int level) {
>     assert(level < ClaimLevels, "Must be");
>     constexpr int array[ClaimLevels]{16, 16, 16};
>     return array[level];
>   }
> 
> 
> When the last statement is changed to:
> 
>     constexpr int result = array[level];
>     return result;
> 
> 
> The MS compiler complains that the expression is not a constant. And if we get the correct inlining the warning goes away.
> 
> To get the required inlining I've changed the `level` parameter to be a template parameter and restructured the code to use template specialization instead of if-statements. This required some finagling with template classes to get partial specialization to work.
> 
> Some other changes in the patch:
> * Limited includes of zIndexDistributor.inline.hpp
> * Extracted the atomic inc into zfetch_then_inc for easier evaluation of the performance impact of our Atomic implementation vs relaxed std::atomic vs non-atomic updates.
> * Hid the logging under a compile-time define. The logging is useful when changing/debugging this code, but otherwise it is not.

This pull request has been closed without being integrated.

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

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

From stuefe at openjdk.org  Thu Jul 31 05:15:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 05:15:54 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v3]
In-Reply-To: <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
 <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
 <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
Message-ID: <KnQk7cUAdVkf-DF_Esm9IIeHCCmAe5cpmRkQu7SSyfY=.59e8bfac-0d10-4dc0-8aa1-7a16103f40b5@github.com>

On Wed, 30 Jul 2025 13:47:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit...
> 
> Based on this description, I'd think `commit_memory_limit` is more accurate in what this function returns. Taking a step further, I'd suggest `reserve_memory_limit` for `address_space_limit`; then it's obvious that they are semantically related and can be placed next to each other.
> 

This makes sense and can also be read in conjunction with os::reserve_memory and os::commit_memory. As in 

// reserve_memory_limit() returns an upper limit beyond which os::reserve_memory
// calls are guaranteed to fail. It is not guaranteed reserving smaller sizes will succeed,
// however.

, and vice versa for commit_memory_limit.

> > to rename has_allocatable_memory_limit() to allocatable_memory_limit()...
> 
> I think PR25450 use bool-return to indicate error-or-not, which is quite diff here. Alternatively, is it possible to change the signature to `size_t x_limit(void)`, returning `size_max` when there is no limit? (Is there a semantic difference btw has-limit-at-size-max and no-limit?)

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3138583960

From stuefe at openjdk.org  Thu Jul 31 05:25:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 05:25:55 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v4]
In-Reply-To: <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
Message-ID: <3StjC1fow5AMsbKvz19itL9G7idYQPBZGLWUSHINxUM=.26770ae0-dfeb-42f5-b21c-aa01b8fa306d@github.com>

On Wed, 30 Jul 2025 09:35:50 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   os:: unification in allocatable_memory_limit

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

> 714: 
> 715: #ifndef _LP64
> 716: // Helper, on 32bit, for os::allocatable_memory_limit

Pre-existing: paying for mmap only to later pay for the same mmap again seems overly costly, seeing that there is no guarantee anyway that the later mmap will also succeed.

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

> 811: 
> 812:   // No limit
> 813:   return SIZE_MAX;

This would be a very nice place to hook in the function I proposed you add, the sister function to `os::vm_min_address()`, let's call it `os::vm_max_address()`.

Looking through the ZGC sources, this is the functionality I meant: https://github.com/openjdk/jdk/blob/559795b0eb8061325127fa9fdf8b80617fe47166/src/hotspot/cpu/aarch64/gc/z/zAddress_aarch64.cpp#L45

For platforms that don't have that implementation, you can still return SIZE_MAX as fallback.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2244378549
PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2244374030

From jsikstro at openjdk.org  Thu Jul 31 07:43:01 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 07:43:01 GMT
Subject: RFR: 8364282: ZGC: Improve ZPageAllocation JFR event sending
In-Reply-To: <pUxOlBYRDJUoS-sk-SkTD0w1yHgOpYjLMboWWykkTtc=.ae8fc5db-8108-4168-85d7-cf862336e63b@github.com>
References: <Rg1gObksjMWKjwjuwdo5i9tO19WBk1g1ucEq5SKUeWw=.bc0d8618-9ba2-4350-8dce-adda0fb88e70@github.com>
 <pUxOlBYRDJUoS-sk-SkTD0w1yHgOpYjLMboWWykkTtc=.ae8fc5db-8108-4168-85d7-cf862336e63b@github.com>
Message-ID: <Xy6VJ7VHGNCfsxdPqQchyV0HzJ6EKtKUzAXDKkDRrqU=.a9376fe9-823f-4742-aab8-4426aa6e606d@github.com>

On Tue, 29 Jul 2025 14:01:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Hello,
>> 
>> This is a follow up to [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), improving on how the ZPageAllocation JFR event is sent. 
>> 
>> The starting time for the event is measured separately from creating a local event varaible (EventZPageAllocation). This means it is better to use the anonymous EventZPageAllocation::commit rather than creating an event and sending that event, which would record the starting time again, unnecessarily.
>> 
>> Additionally, if the event is not enabled (either specifically or if JFR is disabled), we should not waste time sampling statistics for the event.
>> 
>> Testing:
>> * Oracle's tier1-4
>
> Marked as reviewed by stefank (Reviewer).

Thank you for the reviews! @stefank @xmas92

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

PR Comment: https://git.openjdk.org/jdk/pull/26534#issuecomment-3138879922

From jsikstro at openjdk.org  Thu Jul 31 07:43:02 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 07:43:02 GMT
Subject: Integrated: 8364282: ZGC: Improve ZPageAllocation JFR event sending
In-Reply-To: <Rg1gObksjMWKjwjuwdo5i9tO19WBk1g1ucEq5SKUeWw=.bc0d8618-9ba2-4350-8dce-adda0fb88e70@github.com>
References: <Rg1gObksjMWKjwjuwdo5i9tO19WBk1g1ucEq5SKUeWw=.bc0d8618-9ba2-4350-8dce-adda0fb88e70@github.com>
Message-ID: <NmfhP6CtXHZqAHPjmA7wbLkclT_aOO4zp8MWrsv6VOA=.20489b4c-a0f8-4f8f-b13d-ce591806eb13@github.com>

On Tue, 29 Jul 2025 13:51:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This is a follow up to [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), improving on how the ZPageAllocation JFR event is sent. 
> 
> The starting time for the event is measured separately from creating a local event varaible (EventZPageAllocation). This means it is better to use the anonymous EventZPageAllocation::commit rather than creating an event and sending that event, which would record the starting time again, unnecessarily.
> 
> Additionally, if the event is not enabled (either specifically or if JFR is disabled), we should not waste time sampling statistics for the event.
> 
> Testing:
> * Oracle's tier1-4

This pull request has now been integrated.

Changeset: b9f7caed
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9f7caed775e86e71f7d37789cb196fb1444ef12
Stats:     14 lines in 1 file changed: 3 ins; 0 del; 11 mod

8364282: ZGC: Improve ZPageAllocation JFR event sending

Reviewed-by: stefank, aboldtch

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

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

From jsikstro at openjdk.org  Thu Jul 31 07:59:54 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 07:59:54 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v3]
In-Reply-To: <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
 <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
 <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
Message-ID: <NPVEHV187N9m7VWN_WLel1WOkR6LG74sF80DfjB3AHo=.6f649349-5c74-47fa-971c-b6ee626a2083@github.com>

On Wed, 30 Jul 2025 13:47:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> > Just want to start of by saying thank you for taking the time with this.
>>> > > I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
>>> > > "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
>>> > > For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
>>> > > I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.
>>> > 
>>> > 
>>> > I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.
>>> > On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.
>>> 
>>> Maybe it depends on what you need and what question it should answer. Which I don't know. If the question is "what do you think I could allocate at most, were I to try now?"), then yes, allocatableMemory would be good name. It will always be a guess anyway.
>> 
>> I agree that it will always be a guess. What I believe a follow-up to this patch would do is to adjust os::allocatable_memory_limit() to take some user-configurable limit into account on Windows, like Job Objects, which is quite different from how the POSIX implementation works, so having two functions like we have now is needed in some way.
>> 
>> I'm open to changing os::allocatable_memory_limit to something else, maybe something containing the word "commit", since that's what we actually care about. `os::commit_memory_limit()`?
>
>> On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit...
> 
> Based on this description, I'd think `commit_memory_limit` is more accurate in what this function returns. Taking a step further, I'd suggest `reserve_memory_limit` for `address_space_limit`; then it's obvious that they are semantically related and can be placed next to each other.
> 
>> to rename has_allocatable_memory_limit() to allocatable_memory_limit()...
> 
> I think PR25450 use bool-return to indicate error-or-not, which is quite diff here. Alternatively, is it possible to change the signature to `size_t x_limit(void)`, returning `size_max` when there is no limit? (Is there a semantic difference btw has-limit-at-size-max and no-limit?)

I agree with you both, @albertnetymk and @tstuefe, that `commit_memory_limit` and `reserve_memory_limit` are good names and convey the intention of the functions better.

> ```
> // reserve_memory_limit() returns an upper limit beyond which os::reserve_memory
> // calls are guaranteed to fail. It is not guaranteed reserving smaller sizes will succeed,
> // however.
> ```
> 
> , and vice versa for commit_memory_limit.

I also like having this kind of comment above.

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3138930686

From jsikstro at openjdk.org  Thu Jul 31 07:59:56 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 07:59:56 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v4]
In-Reply-To: <3StjC1fow5AMsbKvz19itL9G7idYQPBZGLWUSHINxUM=.26770ae0-dfeb-42f5-b21c-aa01b8fa306d@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
 <3StjC1fow5AMsbKvz19itL9G7idYQPBZGLWUSHINxUM=.26770ae0-dfeb-42f5-b21c-aa01b8fa306d@github.com>
Message-ID: <_m8GN1u4lb2th8DjdKagQbY_ocMsB0mEZxMjtT7C_aw=.1fce584f-b3b7-410b-bda6-9230a2221451@github.com>

On Thu, 31 Jul 2025 05:19:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   os:: unification in allocatable_memory_limit
>
> src/hotspot/os/posix/os_posix.cpp line 813:
> 
>> 811: 
>> 812:   // No limit
>> 813:   return SIZE_MAX;
> 
> This would be a very nice place to hook in the function I proposed you add, the sister function to `os::vm_min_address()`, let's call it `os::vm_max_address()`.
> 
> Looking through the ZGC sources, this is the functionality I meant: https://github.com/openjdk/jdk/blob/559795b0eb8061325127fa9fdf8b80617fe47166/src/hotspot/cpu/aarch64/gc/z/zAddress_aarch64.cpp#L45
> 
> For platforms that don't have that implementation, you can still return SIZE_MAX as fallback.

Yes, this could be nice to have in the future, and would likely be a larger re-write.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2244642891

From jsikstro at openjdk.org  Thu Jul 31 08:48:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 08:48:58 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v5]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <YDT44eNYQpy5nlfqiBXwv7oiYngFcfm_VQ_rFODiXko=.dea3911f-a286-49b9-8ee4-3b397b28588e@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision:

 - Some reordering and comments
 - Rename allocatable_memory_limit to commit_memory_limit
 - Rename address_space_limit to reserve_memory_limit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/9b9d9f7a..47150621

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

  Stats: 42 lines in 5 files changed: 21 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26530/head:pull/26530

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

From jsikstro at openjdk.org  Thu Jul 31 08:48:59 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 08:48:59 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v4]
In-Reply-To: <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
Message-ID: <yjMczd4u1-wve9YLqSiSuTRLEYCiB6r5szeLYUC1CGE=.f97063a1-2432-4499-99e0-f13213ee5111@github.com>

On Wed, 30 Jul 2025 09:35:50 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   os:: unification in allocatable_memory_limit

Pushed three new commits where I rename `address_space_limit` to `reserve_memory_limit`, rename `allocatable_memory_limit` to `commit_memory_limit`, and reordered the header along with adding some describing comments for both functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3139074698

From tschatzl at openjdk.org  Thu Jul 31 08:53:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 08:53:56 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <IoDFQJRMGj-BGkYfvV4oh6IX0co45GCDPFOgaG-YO8E=.e5502e57-b5ec-4812-969f-89a791400042@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <vwFtDSQ8D_Mnk9nA5XvIglfXZq-OwDKCuHRxdU8h6bI=.e3884f55-1c0f-4f8b-883e-72bbae8f2a60@github.com>
 <NqgFS7vAiHjkvdl4-EegARKzxPWYG5gZVq8U2D6GPjY=.dc9be643-f168-464a-a977-8da3d7f3e46e@github.com>
 <gunceDl-r3-IWw4w8nyk70C2z_m7T5OVlVqGzA-6MP0=.e8198891-e978-4c1f-8d72-16a66b0bbf8c@github.com>
 <8FCHTMjSXHFLs5Q8jw9gLgWS-t1jCpRsSPKhR5LCUBE=.d845e003-ba02-47b9-afe2-45309f9adbae@github.com>
 <IoDFQJRMGj-BGkYfvV4oh6IX0co45GCDPFOgaG-YO8E=.e5502e57-b5ec-4812-969f-89a791400042@github.com>
Message-ID: <I0M3nVRWLzHO8XS_bZwdPPFRSz0iEOyQm-uDbu2oh0I=.41867ebf-d4af-4c99-a0a7-00debe085adb@github.com>

On Wed, 30 Jul 2025 20:48:25 GMT, Man Cao <manc at openjdk.org> wrote:

>>> As mentioned in the other comment, concurrent refinement threads typically consume very little CPU compared to concurrent mark workers, and most refinement threads are inactive most of the time. I think bloating up the divisor up to ConcRefinementThreads will undercount the wall-clock time "lost" by mutator threads due to concurrent GC.
>> 
>> What if there is significant concurrent refinement activity? That would unnecessarily expand the heap.
>> 
>> Running one of my go-to benchmarks (some "object storage"; you would not want to run it at that gc cpu usage level, i.e. 55% ;) ) gives the following thread times:
>> 
>> sun.threads.cpu_time.gc_conc_mark=       187537964718
>> sun.threads.cpu_time.gc_conc_refine=    1306781191282
>> sun.threads.cpu_time.gc_parallel_workers=561790592662
>> sun.threads.cpu_time.gc_service=            125919008
>> 
>> Not a very realistic scenario, still I would prefer to not discount refinement costs...
>> 
>> Maybe somehow separate marking and refinment cpu activity and merge again?
>> 
>>> For the other proposed approach using (concurrent-cpu-usage + gc-pause-cpu-usage) as dividend, it is much bigger change of behavior from the pause-time-based approach. I suspect it will suffer from the problem of fluctuating mutator CPU usage (https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14799278), due to using total-cpu-usage-during-mutator in divisor. Perhaps it is better to experiment separately from this PR?
>> 
>> It is a combination of both: for pauses use the existing approach, for mutator time it uses cpu usage.
>> 
>> However I agree that probably it suffers from the same issue, weighing cpu usage too much if the mutator is mostly idle, causing overexpansion.
>
>> Not a very realistic scenario, still I would prefer to not discount refinement costs...
>> Maybe somehow separate marking and refinment cpu activity and merge again?
> 
> Fair enough. Perhaps we need to implement a metric that estimates how many refinement threads are active on average, between two pauses? So we don't overcount or undercount refinement cost.

Another idea is, instead of using application cpu usage in the divisor (i.e. from the OS), calculate some `mutator-cpu-usage` similar to `gc-pause-cpu-usage` by multiplying time spent in mutator with the active processors.

I.e. the resulting formula being:

  gc-time-ratio_new = (concurrent-cpu-usage + gc-pause-cpu-usage) / (mutator-cpu-usage + gc-pause-cpu-usage)
``` 
where

  mutator-cpu-usage = #active processors * mutator-duration

effectively making it:

  gc-time-ratio = (concurrent-cpu-usage + gc-pause-cpu-usage) / (#active processors * time-since-last-pause)

(`gc-pause-cpu-usage` calculated as before).

Which is very similar to the current approach to divide `concurrent-cpu-usage` by some arbitrary threading factor, without needing to know that factor, and incurring inaccuracies because of that.

Compare this formula to the current formula for determing `GCTimeRatio`:

  gc-time-ratio_old = gc-pause-time / time-since-last-pause
                    // multiply with #active-processors on both divisor and dividend, i.e. multiplying by 1
                    = (#active processors * gc-pause-time) / (#active-processors * time-since-last-pause) 


So just adding the known concurrent cpu usage to the dividend seems... straightforward, and no more susceptible to issues than before with idle mutators.

There is dependency on the number of active processors being "constant", but even the old formula uses it implicitly (i.e. the duration of the mutator and the pause is somewhat dependent on the number of active processors anyway due to allocation rate depending on it).

What do you all think? This approximation seems to be no worse than the current and the formula suggested in this change to me. Somebody modifying the number of active processors at runtime for the VM, or something like burstable VMs are already very problematic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2244763473

From tschatzl at openjdk.org  Thu Jul 31 09:08:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 09:08:56 GMT
Subject: RFR: 8359348: G1: Improve cpu usage measurements for heap sizing
 [v3]
In-Reply-To: <I0M3nVRWLzHO8XS_bZwdPPFRSz0iEOyQm-uDbu2oh0I=.41867ebf-d4af-4c99-a0a7-00debe085adb@github.com>
References: <aPTcV5a5yVN0xJ9mrmuxx9grPeAUh1fAs6wxidIt41w=.50dd7e2a-b50b-4251-b635-c03206fa7266@github.com>
 <aOc8GSKIEQlpYbSjtQ3bEX0R95hQgDj8x055RUx0TXc=.4dbea3d3-b551-4ee9-a1db-96f2cf7a2640@github.com>
 <xeZgEKmRFEyeM1bDpUGKx3OnsDMvM2G5o8McTXk99VU=.caa0a5a7-6b01-4a28-a77c-b6f0b03c1a2f@github.com>
 <vwFtDSQ8D_Mnk9nA5XvIglfXZq-OwDKCuHRxdU8h6bI=.e3884f55-1c0f-4f8b-883e-72bbae8f2a60@github.com>
 <NqgFS7vAiHjkvdl4-EegARKzxPWYG5gZVq8U2D6GPjY=.dc9be643-f168-464a-a977-8da3d7f3e46e@github.com>
 <gunceDl-r3-IWw4w8nyk70C2z_m7T5OVlVqGzA-6MP0=.e8198891-e978-4c1f-8d72-16a66b0bbf8c@github.com>
 <8FCHTMjSXHFLs5Q8jw9gLgWS-t1jCpRsSPKhR5LCUBE=.d845e003-ba02-47b9-afe2-45309f9adbae@github.com>
 <IoDFQJRMGj-BGkYfvV4oh6IX0co45GCDPFOgaG-YO8E=.e5502e57-b5ec-4812-969f-89a791400042@github.com>
 <I0M3nVRWLzHO8XS_bZwdPPFRSz0iEOyQm-uDbu2oh0I=.41867ebf-d4af-4c99-a0a7-00debe085adb@github.com>
Message-ID: <_yJlsycZBpjl9wwfv7sUn9Ar19akN4CKPg7i50jF1ws=.7b8ead31-ee56-42f8-b230-2fb97d1f35a4@github.com>

On Thu, 31 Jul 2025 08:48:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Which is very similar to the current approach to divide concurrent-cpu-usage by some arbitrary threading factor, without needing to know that factor, and incurring inaccuracies because of that.

Effectively it divides that concurrent-cpu-usage by the number of active processors if I am not mistaken :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26351#discussion_r2244804255

From jsikstro at openjdk.org  Thu Jul 31 10:20:52 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 10:20:52 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v6]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  commit_memory_limit return size_t instead of bool + out-parameter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/47150621..35d9b9d5

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

  Stats: 42 lines in 4 files changed: 0 ins; 14 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/26530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26530/head:pull/26530

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

From jsikstro at openjdk.org  Thu Jul 31 10:20:53 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 10:20:53 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v3]
In-Reply-To: <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
 <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
 <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
Message-ID: <5Pj1nLLArLZFC2-CPyegguoX_vyM-GgQapvxBU5ACds=.7110da98-3a29-44df-b8fe-b9962ef1307c@github.com>

On Wed, 30 Jul 2025 13:47:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> > Just want to start of by saying thank you for taking the time with this.
>>> > > I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
>>> > > "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
>>> > > For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
>>> > > I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.
>>> > 
>>> > 
>>> > I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.
>>> > On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.
>>> 
>>> Maybe it depends on what you need and what question it should answer. Which I don't know. If the question is "what do you think I could allocate at most, were I to try now?"), then yes, allocatableMemory would be good name. It will always be a guess anyway.
>> 
>> I agree that it will always be a guess. What I believe a follow-up to this patch would do is to adjust os::allocatable_memory_limit() to take some user-configurable limit into account on Windows, like Job Objects, which is quite different from how the POSIX implementation works, so having two functions like we have now is needed in some way.
>> 
>> I'm open to changing os::allocatable_memory_limit to something else, maybe something containing the word "commit", since that's what we actually care about. `os::commit_memory_limit()`?
>
>> On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit...
> 
> Based on this description, I'd think `commit_memory_limit` is more accurate in what this function returns. Taking a step further, I'd suggest `reserve_memory_limit` for `address_space_limit`; then it's obvious that they are semantically related and can be placed next to each other.
> 
>> to rename has_allocatable_memory_limit() to allocatable_memory_limit()...
> 
> I think PR25450 use bool-return to indicate error-or-not, which is quite diff here. Alternatively, is it possible to change the signature to `size_t x_limit(void)`, returning `size_max` when there is no limit? (Is there a semantic difference btw has-limit-at-size-max and no-limit?)

With some suggestions from @albertnetymk, I've changed `commit_memory_limit` to return size_t, just as `reserve_memory_limit`. I think this is reasonable since `commit_memory_limit` should always be bounded by what `reserve_memory_limit` returns anyway, so having both return size_t is good.

I also refactored some of code so that it fits better with the fact that `commit_memory_limit` always returns a value.

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3139357029

From ayang at openjdk.org  Thu Jul 31 10:26:54 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 10:26:54 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v6]
In-Reply-To: <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>
Message-ID: <BfBoVKnSO78UVeDZ9MamLJtn0fklxjydB5wD_aPJWbs=.be939505-8ff6-4068-9a03-92c6658369ad@github.com>

On Thu, 31 Jul 2025 10:20:52 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   commit_memory_limit return size_t instead of bool + out-parameter

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26530#pullrequestreview-3074816051

From stuefe at openjdk.org  Thu Jul 31 10:26:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 10:26:54 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v6]
In-Reply-To: <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>
Message-ID: <EIjadBWUBn0wNauG7_2xHdYXRWACiXtqS2FnuW08MdU=.d511d076-c38d-46a9-a1dd-4aa59ecf9427@github.com>

On Thu, 31 Jul 2025 10:20:52 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   commit_memory_limit return size_t instead of bool + out-parameter

Good.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26530#pullrequestreview-3074822741

From tschatzl at openjdk.org  Thu Jul 31 10:55:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 10:55:38 GMT
Subject: RFR: 8364414: G1: Use simpler data structure for holding collection
 set candidates during calculation
Message-ID: <P5PdvMsR5Zx_S2d1MdqoQWwYGwaQLsvRd8bdgTXuWMo=.9e7a925f-d2f5-4d27-a355-1fad35a2befc@github.com>

Hi all,

  please review this refactoring of the collection set choosing mechanism to use a lighter data structure: instead of an array of `G1CollectionSetCandidateInfo`s, use an array of `G1HeapRegion*` - we do not use the additional information provided by `G1CollectionSetCandidateInfo' at all during that process, and we copy the contents later anyway.

This reduces code complexity a bit (no need to extract the `G1HeapRegion*` from the struct) and reduces memory consumption a little as well.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8364414

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

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

From shade at openjdk.org  Thu Jul 31 11:35:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 11:35:53 GMT
Subject: RFR: 8364183: Shenandoah: Improve commit/uncommit handling
In-Reply-To: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
References: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
Message-ID: <tXoWG3joIbdkbip6SNRR3EcHkCaQB5q6Mnpt4SKziBs=.5e331bc2-7113-4648-bff4-4e4ba85e0659@github.com>

On Mon, 28 Jul 2025 10:34:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While working on related bug, I found that Shenandoah commit/uncommit code has a few issues:
>  1. It throws Java OOME on commit/uncommit failures. These should actually be VM-level out of memory errors, so they are properly fatal.
>  2. Throwing OOME on uncommit looks fairly weird.
>  3. We are not zapping on the newly committed regions. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all`  + `-XX:+UseShenandoahGC`

Thanks! Hotspot rules require 2 reviewers, at least one Reviewer in the area. So I need an ack from e.g. @rkennke @kdnilsen @pengxiaolong, if you can?

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

PR Comment: https://git.openjdk.org/jdk/pull/26502#issuecomment-3139596209

From aboldtch at openjdk.org  Thu Jul 31 13:08:56 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 31 Jul 2025 13:08:56 GMT
Subject: RFR: 8364351: ZGC: Replace usages of ZPageAgeRange() with
 ZPageAgeRangeAll
In-Reply-To: <zVtMciO3XDntgD9F_b9TouGQzugRMp7YYEl9GDHE4D8=.80880a0d-ed53-4415-9e29-5c8271a29f74@github.com>
References: <zVtMciO3XDntgD9F_b9TouGQzugRMp7YYEl9GDHE4D8=.80880a0d-ed53-4415-9e29-5c8271a29f74@github.com>
Message-ID: <WSNKI15R5LjP6lkCHURUMlIHK_BEKMC6Cvj3b-ePFxM=.c96108f0-2bc8-48db-bd16-5ce36eee6c43@github.com>

On Wed, 30 Jul 2025 12:15:34 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> Following up on [JDK-8357053](https://bugs.openjdk.org/browse/JDK-8357053) and [JDK-8358586](https://bugs.openjdk.org/browse/JDK-8358586), this RFE adds a new pre-defined ZPageAge iterator called ZPageAgeRangeAll to iterate over all ages. ZPageAgeRangeAll replaces the usage of `ZPageAgeRange()`, and the ZPageAge gtest is expanded to cover this.
> 
> Testing:
> * Oracle's tier 1-4

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26549#pullrequestreview-3075357843

From aboldtch at openjdk.org  Thu Jul 31 13:10:59 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 31 Jul 2025 13:10:59 GMT
Subject: RFR: 8361897: gc/z/TestUncommit.java fails with Uncommitted too
 slow
In-Reply-To: <HzQi0kdL2Ru747teDdaqfC7I8B_QX0ygPsv5Irr7xxk=.2b9ece78-2ed4-4ba2-b3c7-d7862017fcbb@github.com>
References: <HzQi0kdL2Ru747teDdaqfC7I8B_QX0ygPsv5Irr7xxk=.2b9ece78-2ed4-4ba2-b3c7-d7862017fcbb@github.com>
Message-ID: <K2A-I0xLzy42oOs-2siDJAMeO9uS1JYmk5QRx-Bh8ko=.4d1b7a0d-2ea1-477d-ab30-7f3b9bfc96e5@github.com>

On Tue, 29 Jul 2025 14:58:09 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This proposed change loosens the the threshold for flagging slow un-committing as an error in TestUncommit.java. Rather than requiring the un-committing be completed within 3 ZUncommitDelay, allow up to 5 ZUncommitDelay to accommodate the test being executed in environments where external factors affect whether un-committing is run as expected. 
> 
> In the observed intermittent failures, what can be seen is that the un-committer thread wakes up a significant time after the expected timeout has expired. And because we expect multiple timeouts, the accumulated extra time waiting can push the actual delay just past 3 ZUncommitDelay. Using a factor of 5 instead should remove all but the most extreme intermittent occurrences and still capture if the un-commit logic breaks completely.

Thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26536#issuecomment-3139911444

From aboldtch at openjdk.org  Thu Jul 31 13:11:00 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 31 Jul 2025 13:11:00 GMT
Subject: Integrated: 8361897: gc/z/TestUncommit.java fails with Uncommitted too
 slow
In-Reply-To: <HzQi0kdL2Ru747teDdaqfC7I8B_QX0ygPsv5Irr7xxk=.2b9ece78-2ed4-4ba2-b3c7-d7862017fcbb@github.com>
References: <HzQi0kdL2Ru747teDdaqfC7I8B_QX0ygPsv5Irr7xxk=.2b9ece78-2ed4-4ba2-b3c7-d7862017fcbb@github.com>
Message-ID: <dbRSl8k0rEHVI99VY5oben1w80vGbSa7XlE6SWorN-Q=.89606297-ac05-4e38-a3f9-d0003d5daac7@github.com>

On Tue, 29 Jul 2025 14:58:09 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This proposed change loosens the the threshold for flagging slow un-committing as an error in TestUncommit.java. Rather than requiring the un-committing be completed within 3 ZUncommitDelay, allow up to 5 ZUncommitDelay to accommodate the test being executed in environments where external factors affect whether un-committing is run as expected. 
> 
> In the observed intermittent failures, what can be seen is that the un-committer thread wakes up a significant time after the expected timeout has expired. And because we expect multiple timeouts, the accumulated extra time waiting can push the actual delay just past 3 ZUncommitDelay. Using a factor of 5 instead should remove all but the most extreme intermittent occurrences and still capture if the un-commit logic breaks completely.

This pull request has now been integrated.

Changeset: 3f21c8bd
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f21c8bd1f0cd7f27df940505b249ba7798940cf
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8361897: gc/z/TestUncommit.java fails with Uncommitted too slow

Reviewed-by: stefank, jsikstro

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

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

From tschatzl at openjdk.org  Thu Jul 31 13:35:20 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 13:35:20 GMT
Subject: RFR: 8364414: G1: Use simpler data structure for holding
 collection set candidates during calculation [v2]
In-Reply-To: <P5PdvMsR5Zx_S2d1MdqoQWwYGwaQLsvRd8bdgTXuWMo=.9e7a925f-d2f5-4d27-a355-1fad35a2befc@github.com>
References: <P5PdvMsR5Zx_S2d1MdqoQWwYGwaQLsvRd8bdgTXuWMo=.9e7a925f-d2f5-4d27-a355-1fad35a2befc@github.com>
Message-ID: <1yNuabPYEkaNRSCQnDveI6hVfxoRrNT-3oFTj77Enn0=.062061ec-5ef7-44d6-87c5-caff8c3d034f@github.com>

> Hi all,
> 
>   please review this refactoring of the collection set choosing mechanism to use a lighter data structure: instead of an array of `G1CollectionSetCandidateInfo`s, use an array of `G1HeapRegion*` - we do not use the additional information provided by `G1CollectionSetCandidateInfo` at all during that process, and we copy the contents later anyway.
> 
> This reduces code complexity a bit (no need to extract the `G1HeapRegion*` from the struct) and reduces memory consumption a little as well.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

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

  * fix sort function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26572/files
  - new: https://git.openjdk.org/jdk/pull/26572/files/213e156b..c254b942

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

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

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

From tschatzl at openjdk.org  Thu Jul 31 14:10:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 14:10:07 GMT
Subject: RFR: 8364423: G1: Refactor
 G1UpdateRegionLivenessAndSelectForRebuildTask
Message-ID: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>

Hi all,

  please review this refactoring of `G1UpdateRegionLivenessAndSelectForRebuildTask` to remove some code duplication, which makes it simpler to add more common code

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - * fix whitespace
 - 8364423

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

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

From ayang at openjdk.org  Thu Jul 31 14:35:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 14:35:00 GMT
Subject: RFR: 8364414: G1: Use simpler data structure for holding
 collection set candidates during calculation [v2]
In-Reply-To: <1yNuabPYEkaNRSCQnDveI6hVfxoRrNT-3oFTj77Enn0=.062061ec-5ef7-44d6-87c5-caff8c3d034f@github.com>
References: <P5PdvMsR5Zx_S2d1MdqoQWwYGwaQLsvRd8bdgTXuWMo=.9e7a925f-d2f5-4d27-a355-1fad35a2befc@github.com>
 <1yNuabPYEkaNRSCQnDveI6hVfxoRrNT-3oFTj77Enn0=.062061ec-5ef7-44d6-87c5-caff8c3d034f@github.com>
Message-ID: <JqdZev90YdKpy8ofxdR5onBjVM-1vHNHfPNQjdm_Cx0=.15953bba-c97b-420b-8606-2e9de37d70ff@github.com>

On Thu, 31 Jul 2025 13:35:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this refactoring of the collection set choosing mechanism to use a lighter data structure: instead of an array of `G1CollectionSetCandidateInfo`s, use an array of `G1HeapRegion*` - we do not use the additional information provided by `G1CollectionSetCandidateInfo` at all during that process, and we copy the contents later anyway.
>> 
>> This reduces code complexity a bit (no need to extract the `G1HeapRegion*` from the struct) and reduces memory consumption a little as well.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * fix sort function

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26572#pullrequestreview-3075695649

From ayang at openjdk.org  Thu Jul 31 14:44:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 14:44:10 GMT
Subject: RFR: 8364423: G1: Refactor
 G1UpdateRegionLivenessAndSelectForRebuildTask
In-Reply-To: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>
References: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>
Message-ID: <o57x2W0FppVAT7tdtyqPTcwC5t1lbRogmbIw26MosmE=.a6a7f8de-8898-49d2-a43e-cce139098135@github.com>

On Thu, 31 Jul 2025 12:07:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this refactoring of `G1UpdateRegionLivenessAndSelectForRebuildTask` to remove some code duplication, which makes it simpler to add more common code
> 
> Testing: gha
> 
> Thanks,
>   Thomas

A minor subjective suggestion, but up to you.

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

> 1260:       }
> 1261:       _cm->update_top_at_rebuild_start(hr);
> 1262:     }

I feel this logic is too caller-specific -- reading its name `update_live_region` doesn't reveal much what this method should do/deliver.

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26574#pullrequestreview-3075725547
PR Review Comment: https://git.openjdk.org/jdk/pull/26574#discussion_r2245596038

From shade at openjdk.org  Thu Jul 31 14:49:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 14:49:35 GMT
Subject: RFR: 8358340: Support CDS heap archive with Generational Shenandoah
Message-ID: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>

Now that [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) is integrated, Generational Shenandoah can support CDS heap loads. This also allows Generational Shenandoah to work well with Leyden/AOT. We allocate things in young regions, and there is nothing else in the heap, so no card table updates are necessary.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
 - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational`
 - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:+ShenandoahVerify`

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

Commit messages:
 - Fix

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

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

From shade at openjdk.org  Thu Jul 31 14:49:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 14:49:35 GMT
Subject: RFR: 8358340: Support CDS heap archive with Generational
 Shenandoah
In-Reply-To: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
References: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
Message-ID: <cZRhxX88xeFGenyIzanUR1fLKOZConpYRNWhVfcqQ98=.aacc0f96-c0a8-43cc-87f7-b1ce5dede5a2@github.com>

On Mon, 2 Jun 2025 18:22:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) is integrated, Generational Shenandoah can support CDS heap loads. This also allows Generational Shenandoah to work well with Leyden/AOT. We allocate things in young regions, and there is nothing else in the heap, so no card table updates are necessary.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:+ShenandoahVerify`

Debugging breadcrumbs: this seems to still fail intermittently:


$ CONF=linux-x86_64-server-fastdebug make test TEST=gc/shenandoah/TestAllocIntArrays.java JTREG=REPEAT_COUNT=10

#  Internal Error (/home/shade/trunks/jdk/src/hotspot/share/memory/iterator.inline.hpp:59), pid=1222144, tid=1222159
#  assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k)) failed: sanity: java.lang.module.ModuleDescriptor$Modifier

Stack: [0x000071e2112d3000,0x000071e2113d3000],  sp=0x000071e2113d1930,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x3bad37]  ClaimMetadataVisitingOopIterateClosure::do_klass(Klass*)+0x427  (iterator.inline.hpp:59)
V  [libjvm.so+0x1afeb11]  void InstanceMirrorKlass::oop_oop_iterate_bounded<narrowOop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2> >(oop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2>*, MemRegion)+0x9d1  (devirtualizer.inline.hpp:126)
V  [libjvm.so+0x1afec75]  void OopOopIterateBoundedDispatch<ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2> >::Table::oop_oop_iterate_bounded<InstanceMirrorKlass, narrowOop>(ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2>*, oop, Klass*, MemRegion)+0x65  (iterator.inline.hpp:182)
V  [libjvm.so+0x1af6285]  void ShenandoahScanRemembered::process_clusters<ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2> >(unsigned long, unsigned long, HeapWordImpl**, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2>*, bool, unsigned int)+0x8d5  (iterator.inline.hpp:306)
V  [libjvm.so+0x1af0c8d]  ShenandoahScanRememberedTask::do_work(unsigned int)+0xb1d  (shenandoahScanRemembered.inline.hpp:359)
V  [libjvm.so+0x1af0e4c]  ShenandoahScanRememberedTask::work(unsigned int)+0xcc  (shenandoahScanRemembered.cpp:664)
V  [libjvm.so+0x1e52348]  WorkerThread::run()+0x88  (workerThread.cpp:69)
V  [libjvm.so+0x1cf321a]  Thread::call_run()+0xba  (thread.cpp:243)
V  [libjvm.so+0x17a78c8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:868)
C  [libc.so.6+0x9caa4]


That assert seems to mean that the CLD for the class in question is `nullptr`.

All right, I think I found a non-Shenandoah bug: [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25597#issuecomment-3114216592
PR Comment: https://git.openjdk.org/jdk/pull/25597#issuecomment-3117880099

From xpeng at openjdk.org  Thu Jul 31 14:50:01 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 31 Jul 2025 14:50:01 GMT
Subject: RFR: 8364183: Shenandoah: Improve commit/uncommit handling
In-Reply-To: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
References: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
Message-ID: <ZGBzMhUhWKlbm0AG0JUBvQ-tL_AUjUk9bw68paCBbPs=.0f6e5dde-c534-4d56-8977-357ad1babd31@github.com>

On Mon, 28 Jul 2025 10:34:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While working on related bug, I found that Shenandoah commit/uncommit code has a few issues:
>  1. It throws Java OOME on commit/uncommit failures. These should actually be VM-level out of memory errors, so they are properly fatal.
>  2. Throwing OOME on uncommit looks fairly weird.
>  3. We are not zapping on the newly committed regions. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all`  + `-XX:+UseShenandoahGC`

Looks good to me, thank you!

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

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26502#pullrequestreview-3075754366

From shade at openjdk.org  Thu Jul 31 15:21:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 15:21:00 GMT
Subject: RFR: 8364183: Shenandoah: Improve commit/uncommit handling
In-Reply-To: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
References: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
Message-ID: <WZDS7QOcV44ldA6qinshwf2XVw4hOGUVNFPoDuSZBC0=.874960ca-a0f3-44b8-abc1-017fc483a362@github.com>

On Mon, 28 Jul 2025 10:34:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While working on related bug, I found that Shenandoah commit/uncommit code has a few issues:
>  1. It throws Java OOME on commit/uncommit failures. These should actually be VM-level out of memory errors, so they are properly fatal.
>  2. Throwing OOME on uncommit looks fairly weird.
>  3. We are not zapping on the newly committed regions. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all`  + `-XX:+UseShenandoahGC`

Thanks! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26502#issuecomment-3140369815

From shade at openjdk.org  Thu Jul 31 15:21:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 15:21:01 GMT
Subject: Integrated: 8364183: Shenandoah: Improve commit/uncommit handling
In-Reply-To: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
References: <WqHDGjOVnL82HPlKPZ8Z-D51z0zEIh3Rw2uRj2tc89E=.7fa487a7-d96f-4322-ae25-8a6c14143b98@github.com>
Message-ID: <Tiony_Xwx1qHo9v8bE7H8LrQg251OY8IVz8_iV56cEQ=.5e9bfe22-329d-41f5-b862-1df0b051475b@github.com>

On Mon, 28 Jul 2025 10:34:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While working on related bug, I found that Shenandoah commit/uncommit code has a few issues:
>  1. It throws Java OOME on commit/uncommit failures. These should actually be VM-level out of memory errors, so they are properly fatal.
>  2. Throwing OOME on uncommit looks fairly weird.
>  3. We are not zapping on the newly committed regions. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all`  + `-XX:+UseShenandoahGC`

This pull request has now been integrated.

Changeset: 1b9efaa1
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b9efaa11e660317240bdeda7527b23c7d52da0f
Stats:     59 lines in 3 files changed: 20 ins; 14 del; 25 mod

8364183: Shenandoah: Improve commit/uncommit handling

Reviewed-by: wkemper, xpeng

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

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

From tschatzl at openjdk.org  Thu Jul 31 15:25:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 15:25:57 GMT
Subject: RFR: 8364423: G1: Refactor
 G1UpdateRegionLivenessAndSelectForRebuildTask
In-Reply-To: <o57x2W0FppVAT7tdtyqPTcwC5t1lbRogmbIw26MosmE=.a6a7f8de-8898-49d2-a43e-cce139098135@github.com>
References: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>
 <o57x2W0FppVAT7tdtyqPTcwC5t1lbRogmbIw26MosmE=.a6a7f8de-8898-49d2-a43e-cce139098135@github.com>
Message-ID: <O-tVDUCxbXTvW5hP4TITYPiPJKDTEdJJ8ggvBe6mKuA=.dc1ca197-a7fd-47d8-b46c-cbc41bd15aa7@github.com>

On Thu, 31 Jul 2025 14:39:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this refactoring of `G1UpdateRegionLivenessAndSelectForRebuildTask` to remove some code duplication, which makes it simpler to add more common code
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 1262:
> 
>> 1260:       }
>> 1261:       _cm->update_top_at_rebuild_start(hr);
>> 1262:     }
> 
> I feel this logic is too caller-specific -- reading its name `update_live_region` doesn't reveal much what this method should do/deliver.

Since it is the same, and the only per-region work to do for all callers, not sure what is caller-specific here. Maybe change the name to something like `update_for_rebuild` is more appropriate? Or just leave it as is until more common work needs to be done?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26574#discussion_r2245707249

From tschatzl at openjdk.org  Thu Jul 31 15:27:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 15:27:56 GMT
Subject: RFR: 8364254: Serial: Remove soft ref policy update in WhiteBox
 FullGC
In-Reply-To: <MQ31Ok-NNG66SPysEMeFjYBm3CoK49RWqGjWL1_CPyc=.395d2819-ffb2-4635-8ec2-51cc78a63a7e@github.com>
References: <MQ31Ok-NNG66SPysEMeFjYBm3CoK49RWqGjWL1_CPyc=.395d2819-ffb2-4635-8ec2-51cc78a63a7e@github.com>
Message-ID: <FSLT8KG5XaydwxLbsw7tWkAcjOGcv0PoCEyB8Eebc9s=.63a5c4d5-63e0-46b7-bcce-674df79897da@github.com>

On Tue, 29 Jul 2025 09:37:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already.
> 
> Test: tier1-3

Seems good.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26528#pullrequestreview-3075898221

From ayang at openjdk.org  Thu Jul 31 15:37:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 15:37:55 GMT
Subject: RFR: 8364423: G1: Refactor
 G1UpdateRegionLivenessAndSelectForRebuildTask
In-Reply-To: <O-tVDUCxbXTvW5hP4TITYPiPJKDTEdJJ8ggvBe6mKuA=.dc1ca197-a7fd-47d8-b46c-cbc41bd15aa7@github.com>
References: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>
 <o57x2W0FppVAT7tdtyqPTcwC5t1lbRogmbIw26MosmE=.a6a7f8de-8898-49d2-a43e-cce139098135@github.com>
 <O-tVDUCxbXTvW5hP4TITYPiPJKDTEdJJ8ggvBe6mKuA=.dc1ca197-a7fd-47d8-b46c-cbc41bd15aa7@github.com>
Message-ID: <WG5PY4ENEDzBiU72jFkMbQFUnHnOrQr1dRFYku_dt14=.1d9212cd-b3f9-433f-abb1-4b038a7362dc@github.com>

On Thu, 31 Jul 2025 15:23:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 1262:
>> 
>>> 1260:       }
>>> 1261:       _cm->update_top_at_rebuild_start(hr);
>>> 1262:     }
>> 
>> I feel this logic is too caller-specific -- reading its name `update_live_region` doesn't reveal much what this method should do/deliver.
>
> Since it is the same, and the only per-region work to do for all callers, not sure what is caller-specific here. Maybe change the name to something like `update_for_rebuild` is more appropriate? Or just leave it as is until more common work needs to be done?

Usually, it's the method spec that determines its impl, because a method doesn't know all the callers. However, give its name + signature, it's unclear what the impl should be -- instead, it's determined by its caller context (select-for-rebuild), hence, caller-specific.

> Or just leave it as is until more common work needs to be done?

Maybe by then some common logic can be extracted into a self-contained method.

YMMV.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26574#discussion_r2245738251

From tschatzl at openjdk.org  Thu Jul 31 16:35:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 16:35:41 GMT
Subject: RFR: 8364423: G1: Refactor
 G1UpdateRegionLivenessAndSelectForRebuildTask [v2]
In-Reply-To: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>
References: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>
Message-ID: <WDFEECs9iBmfueIRJZjPydrUblHHrD-ZbrEu-epQl2I=.0aa6e682-5455-4a14-ba0d-81384e1ab57c@github.com>

> Hi all,
> 
>   please review this refactoring of `G1UpdateRegionLivenessAndSelectForRebuildTask` to remove some code duplication, which makes it simpler to add more common code
> 
> Testing: gha
> 
> Thanks,
>   Thomas

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

  * undo factoring out common code when preparing for rebuild.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26574/files
  - new: https://git.openjdk.org/jdk/pull/26574/files/0704afba..90aa50dd

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

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

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

From tschatzl at openjdk.org  Thu Jul 31 16:39:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 16:39:35 GMT
Subject: RFR: 8364423: G1: Refactor
 G1UpdateRegionLivenessAndSelectForRebuildTask [v3]
In-Reply-To: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>
References: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>
Message-ID: <YNSUvHcTLZ9xXjgBTp914x_j6RbI_5jISdYKDeplX64=.e24b870c-be92-4377-aa91-caf9351e0958@github.com>

> Hi all,
> 
>   please review this refactoring of `G1UpdateRegionLivenessAndSelectForRebuildTask` to remove some code duplication, which makes it simpler to add more common code
> 
> Testing: gha
> 
> Thanks,
>   Thomas

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

 - * readding blank line too
 - * indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26574/files
  - new: https://git.openjdk.org/jdk/pull/26574/files/90aa50dd..e0654633

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

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

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

From xpeng at openjdk.org  Thu Jul 31 17:31:53 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 31 Jul 2025 17:31:53 GMT
Subject: RFR: 8358340: Support CDS heap archive with Generational
 Shenandoah
In-Reply-To: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
References: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
Message-ID: <b7DLgY4kplTSVkeVbZ50XewPdZeVvYKfA-omK66NwUo=.ee4aa3fc-079a-4186-a62c-76cec00758d0@github.com>

On Mon, 2 Jun 2025 18:22:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) is integrated, Generational Shenandoah can support CDS heap loads. This also allows Generational Shenandoah to work well with Leyden/AOT. We allocate things in young regions, and there is nothing else in the heap, so no card table updates are necessary.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:+ShenandoahVerify`

LGTM!

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

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25597#pullrequestreview-3076329852

From sangheki at openjdk.org  Thu Jul 31 18:13:55 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Thu, 31 Jul 2025 18:13:55 GMT
Subject: RFR: 8364166: Parallel: Remove the use of soft_ref_policy in Full
 GC [v2]
In-Reply-To: <HD7TOLCfwzE7FmH-92RGKc8O6epNbJQwaHUuacE3jXk=.7aef4544-bbdd-4a38-9ef9-866a4ab11391@github.com>
References: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
 <HD7TOLCfwzE7FmH-92RGKc8O6epNbJQwaHUuacE3jXk=.7aef4544-bbdd-4a38-9ef9-866a4ab11391@github.com>
Message-ID: <bEfwz03w0Og4HkUNDXFz_gpnE6dXXQObV9jO4EfVScU=.5afb6a03-75a3-4990-a5b6-7e24ce403c3f@github.com>

On Tue, 29 Jul 2025 08:20:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple removing redundant soft-ref-clearing checking in full-gc, because Parallel already reacts to this particular gc-cause, `_wb_full_gc`.
>> 
>> 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 three additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-soft-ref
>  - pgc-soft-ref

Looks good.

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

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26496#pullrequestreview-3076442917

From sangheki at openjdk.org  Thu Jul 31 18:32:56 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Thu, 31 Jul 2025 18:32:56 GMT
Subject: RFR: 8364176: Serial: Group all class unloading logic at the end
 of marking phase
In-Reply-To: <kTY3bfZzrTYX03I7HuEzGHn0QmeJmnoh6_6NPazsOkE=.54fc7b78-9bf1-499a-bac3-22f433348251@github.com>
References: <kTY3bfZzrTYX03I7HuEzGHn0QmeJmnoh6_6NPazsOkE=.54fc7b78-9bf1-499a-bac3-22f433348251@github.com>
Message-ID: <DKruo5RUvmGBgvGBeTmTd7HH3PdiZEpQbVOVMwTbcqE=.b040682b-e655-4486-aba8-fcbeff629804@github.com>

On Mon, 28 Jul 2025 08:54:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple moving some classunloading logic inside `SerialFullGC`.
> 
> Test: tier1

Looks good.

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

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26499#pullrequestreview-3076491468

From ayang at openjdk.org  Thu Jul 31 18:58:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 18:58:05 GMT
Subject: RFR: 8364176: Serial: Group all class unloading logic at the end
 of marking phase
In-Reply-To: <kTY3bfZzrTYX03I7HuEzGHn0QmeJmnoh6_6NPazsOkE=.54fc7b78-9bf1-499a-bac3-22f433348251@github.com>
References: <kTY3bfZzrTYX03I7HuEzGHn0QmeJmnoh6_6NPazsOkE=.54fc7b78-9bf1-499a-bac3-22f433348251@github.com>
Message-ID: <LRfJp-ytrSH_iUMyXfk9ob6iOeRZG6-3ZBPjfEP3UKU=.6786bd2c-87b7-4e51-9cf7-cd1b07607eed@github.com>

On Mon, 28 Jul 2025 08:54:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple moving some classunloading logic inside `SerialFullGC`.
> 
> Test: tier1

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26499#issuecomment-3141011604

From ayang at openjdk.org  Thu Jul 31 18:58:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 18:58:06 GMT
Subject: RFR: 8364166: Parallel: Remove the use of soft_ref_policy in Full
 GC [v2]
In-Reply-To: <HD7TOLCfwzE7FmH-92RGKc8O6epNbJQwaHUuacE3jXk=.7aef4544-bbdd-4a38-9ef9-866a4ab11391@github.com>
References: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
 <HD7TOLCfwzE7FmH-92RGKc8O6epNbJQwaHUuacE3jXk=.7aef4544-bbdd-4a38-9ef9-866a4ab11391@github.com>
Message-ID: <tsgeiMQGCzATJh63HrzQWWIcI0S4OH7PGXStCaVUF68=.93938ded-94ea-4a5f-9254-53a4c3fd54c1@github.com>

On Tue, 29 Jul 2025 08:20:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple removing redundant soft-ref-clearing checking in full-gc, because Parallel already reacts to this particular gc-cause, `_wb_full_gc`.
>> 
>> 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 three additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-soft-ref
>  - pgc-soft-ref

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26496#issuecomment-3141010599

From ayang at openjdk.org  Thu Jul 31 18:58:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 18:58:05 GMT
Subject: Integrated: 8364176: Serial: Group all class unloading logic at the
 end of marking phase
In-Reply-To: <kTY3bfZzrTYX03I7HuEzGHn0QmeJmnoh6_6NPazsOkE=.54fc7b78-9bf1-499a-bac3-22f433348251@github.com>
References: <kTY3bfZzrTYX03I7HuEzGHn0QmeJmnoh6_6NPazsOkE=.54fc7b78-9bf1-499a-bac3-22f433348251@github.com>
Message-ID: <cKboqYnMFnPZz1AOReFrctc2srLwW1piPHVHFroiH4E=.48263d77-5dc3-4713-a7ee-8bc31ef300a5@github.com>

On Mon, 28 Jul 2025 08:54:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple moving some classunloading logic inside `SerialFullGC`.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 443afdc7
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/443afdc77ffb9184a985ec586c888eabe9ee8e6f
Stats:     22 lines in 2 files changed: 9 ins; 10 del; 3 mod

8364176: Serial: Group all class unloading logic at the end of marking phase

Reviewed-by: tschatzl, sangheki

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

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

From ayang at openjdk.org  Thu Jul 31 18:58:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 18:58:07 GMT
Subject: Integrated: 8364166: Parallel: Remove the use of soft_ref_policy in
 Full GC
In-Reply-To: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
References: <lUPMSmtksc73ZaWacdrf2Tp7WhRw7b2TZmraTH7k5Hc=.ae1522e0-cbaa-4bd0-a0ce-e2f955b5968f@github.com>
Message-ID: <oNqOpomkLzRu0QbV1p3hv_sH4nKitFu8p4QS0vQl_3E=.6f26bb44-c14b-47be-afea-4d1095a831b0@github.com>

On Mon, 28 Jul 2025 08:00:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing redundant soft-ref-clearing checking in full-gc, because Parallel already reacts to this particular gc-cause, `_wb_full_gc`.
> 
> Test: tier1-3

This pull request has now been integrated.

Changeset: e0e82066
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e0e82066fec3e1efa55ecc113bb8f4efe2e0e2a0
Stats:     21 lines in 2 files changed: 0 ins; 17 del; 4 mod

8364166: Parallel: Remove the use of soft_ref_policy in Full GC

Reviewed-by: tschatzl, sangheki

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

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

From sangheki at openjdk.org  Thu Jul 31 19:01:04 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Thu, 31 Jul 2025 19:01:04 GMT
Subject: RFR: 8364423: G1: Refactor
 G1UpdateRegionLivenessAndSelectForRebuildTask [v3]
In-Reply-To: <YNSUvHcTLZ9xXjgBTp914x_j6RbI_5jISdYKDeplX64=.e24b870c-be92-4377-aa91-caf9351e0958@github.com>
References: <YNWANw-BQxbNSTib_BGuKRa-oXTsk8hfZKmsmE20R_I=.d65c887d-ef69-43d1-a52f-8e02d5bf427a@github.com>
 <YNSUvHcTLZ9xXjgBTp914x_j6RbI_5jISdYKDeplX64=.e24b870c-be92-4377-aa91-caf9351e0958@github.com>
Message-ID: <EdR9jaH0-gyKV_N75VnXtkgLDuWqq_D8ZsGNZ0dYSTE=.505bec9b-ecac-4cc8-91f3-9a6228a8c8d6@github.com>

On Thu, 31 Jul 2025 16:39:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this refactoring of `G1UpdateRegionLivenessAndSelectForRebuildTask` to remove some code duplication, which makes it simpler to add more common code
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - * readding blank line too
>  - * indentation

LGTM

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

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26574#pullrequestreview-3076578415

From wkemper at openjdk.org  Thu Jul 31 19:14:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 31 Jul 2025 19:14:56 GMT
Subject: RFR: 8358340: Support CDS heap archive with Generational
 Shenandoah
In-Reply-To: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
References: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
Message-ID: <WuELZjqrXcB8v7H1RXKrdN_7VPkroiPq0PEhsBSAIyc=.412d1f95-8d9c-4da8-ad2d-70cef3488a48@github.com>

On Mon, 2 Jun 2025 18:22:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) is integrated, Generational Shenandoah can support CDS heap loads. This also allows Generational Shenandoah to work well with Leyden/AOT. We allocate things in young regions, and there is nothing else in the heap, so no card table updates are necessary.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:+ShenandoahVerify`

Also looks good to me.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25597#pullrequestreview-3076617332

From mbeckwit at openjdk.org  Thu Jul 31 21:15:59 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 31 Jul 2025 21:15:59 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <y84Sr_Pvl3CTKlVngL3zNqG-dujfk5dxgDOjcZJ_lC4=.737cc414-7375-4904-a7f0-6b51eae6281b@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
 <2AgG77y3-6NXn1ztkmUWgSLk7ldhKq5Pd1EfAV9cAO4=.d463af22-5fd0-4d47-a758-1e5319af1955@github.com>
 <BycMAws6MDgTjdcuOnelo3nS41ctUnT1ulfM1UepbZk=.b94e7398-74b7-46a7-a1d1-5e59ed075a76@github.com>
 <y84Sr_Pvl3CTKlVngL3zNqG-dujfk5dxgDOjcZJ_lC4=.737cc414-7375-4904-a7f0-6b51eae6281b@github.com>
Message-ID: <IvuSDVc_wLy7t9q7ZDB_WjlFAHSyrJwzJ6jugTE50nU=.130cc203-8209-43bc-a5f0-5fe82f20305a@github.com>

On Thu, 17 Jul 2025 07:32:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Release-note howto: https://openjdk.org/guide/index.html#release-notes. For now I tagged the issue with `release-note=yes`. Note that it can be written later.
>
> One reason why I do not see the need for these flags to be manageable is that this heap shrinking is a supportive function if the application is "idle". Main heap sizing should be done by the existing heap sizing/AHS at GC events.
> 
> From the CR text:
>>  Doing heap sizing based on garbage collections has a big disadvantage: if there are no garbage collections (due to no application activity) there is a risk that a large amount of heap is kept committed unnecessarily *for a long time*. 
> (emphasis mine)
> 
> If we are talking about "a long time", so there does not seem to be a need for changing it during runtime (or change it at all). It should not matter if that "long time" is "long time +- small epsilon", and so, allowing dynamic change of "a long time" to another "long time" seems unnecessary without a very good use case.
> 
> Please consider not necessarily the current situation, but with "full" AHS.
> 
> Another question is whether you had thoughts about the interaction with (JDK-8213198)[https://bugs.openjdk.org/browse/JDK-8213198], as this change seems to be a subset of the other. (That's just curiosity from me, I think this feature is useful as is, and if the other ever materializes, we can always reconsider).
> 
> Otoh decreasing the heap by this mechanism will eventually trigger a marking.

@tschatzl Thanks for the detailed feedback! 
Flag Changes (per your feedback):

- G1UseTimeBasedHeapSizing is now diagnostic and enabled by default (was experimental/disabled).
- G1MinRegionsToUncommit is now diagnostic (was experimental).
- Timing flags (G1UncommitDelayMillis, G1TimeBasedEvaluationIntervalMillis) remain manageable to support operational use cases.


## Manageable Flag Use Cases
I can see 3 scenarios where runtime adjustment is valuable:

**High-Availability Services**
- 24/7 operations cannot restart for tuning adjustments  
- Memory pressure events require immediate response
- Cost optimization demands dynamic resource adaptation

**Cloud & Container Platforms**  
- Resource limits change dynamically (auto-scaling)
- Multi-tenancy requires per-workload optimization
- Cost efficiency drives aggressive memory reclaim

**DevOps & SRE Teams**
- Incident response needs immediate memory reclaim
- Performance testing requires runtime comparison of settings  
- Capacity planning benefits from live tuning experiments

## "Long Time" Consideration
While the feature targets 'long idle periods,' production shows varied patterns where the difference between 5 minutes vs 30 seconds becomes critical - especially in container environments where exceeding memory limits means process termination, not just performance degradation.

## JDK-8213198 Interaction  
After reviewing that issue, I see they address **orthogonal problems**:

**JDK-8213198**: Active application, young GCs happening, needs mixed GCs for string table cleanup
**JDK-8357445**: Idle application, no GCs happening, needs memory uncommit

**Operational States:**
- String table issue: Active allocation + insufficient mixed GCs  
- Time-based uncommit: Complete inactivity + no allocations

**Complementary Solutions:**
- JDK-8213198: Triggers concurrent cycles when string table grows
- JDK-8357445: Uncommits memory during idle periods
- Future full AHS: Would orchestrate both mechanisms

The manageable flags become critical in the idle scenario where container memory limits create immediate pressure, unlike the string table scenario where growth can be tolerated for longer periods.

Would this clarification help with the flag classification decision?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2246389289

From mbeckwit at openjdk.org  Thu Jul 31 23:40:52 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 31 Jul 2025 23:40:52 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v5]
In-Reply-To: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
Message-ID: <1YLyjSz8paefxLT9OoI1y3IH1o7xQYt9fkeztut7uHI=.e9d18d00-8561-4c05-a917-c2d0ab4d1d7d@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

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

  JDK-8357445: Implement @tschatzl code review feedback for time-based heap sizing
  
  - Convert from jlong milliseconds to proper time types (Ticks/Tickspan)
  - Reclassify G1UseTimeBasedHeapSizing from EXPERIMENTAL+false to DIAGNOSTIC+true
  - Reclassify G1MinRegionsToUncommit from EXPERIMENTAL to DIAGNOSTIC
  - Keep timing flags (G1UncommitDelayMillis, G1HeapEvaluationIntervalMillis) as MANAGEABLE
  - Update all test files to use UnlockDiagnosticVMOptions instead of UnlockExperimentalVMOptions
  - Remove explicit G1UseTimeBasedHeapSizing=true from tests (now enabled by default)
  - Improve logging terminology from 'time-based' to 'uncommit evaluation'
  - Fix comment style and remove unused heap_sizing_policy() accessor
  - Comprehensive type safety improvements throughout the codebase
  
  This addresses all feedback regarding type safety, flag design,
  and production readiness of the time-based heap sizing feature.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26240/files
  - new: https://git.openjdk.org/jdk/pull/26240/files/23a732e6..53a79368

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

  Stats: 69 lines in 12 files changed: 3 ins; 10 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/26240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240

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