From ayang at openjdk.org  Thu Jan  2 06:34:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Jan 2025 06:34:43 GMT
Subject: RFR: 8345374: Ubsan: runtime error: division by zero
In-Reply-To: <zhB3t1eDrmm2hgi42U6sYXhBm1zTtvYCjr3gKZbrEe4=.ab63227b-8365-4841-9649-591fcd63a487@github.com>
References: <zhB3t1eDrmm2hgi42U6sYXhBm1zTtvYCjr3gKZbrEe4=.ab63227b-8365-4841-9649-591fcd63a487@github.com>
Message-ID: <N5IGjtxcY2yCBfGA9TrQLEvp20BRov_X5pRzsozXmvM=.a3ca6fb6-933b-4dfe-8ce8-7b43dcd86381@github.com>

On Mon, 30 Dec 2024 01:07:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to G1HeapSizingPolicy to avoid a float division by
> zero when calculating the maximum desired capacity with a MaxHeapFreeRatio
> value of 100%.
> 
> Testing: mach5 tier1 with G1 and MaxHeapFreeRatio=100.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22893#pullrequestreview-2527075314

From ayang at openjdk.org  Thu Jan  2 06:38:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Jan 2025 06:38:43 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before GC
Message-ID: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>

This PR introduces a new strategy to determine whether an allocation should be attempted in the old generation or if a GC cycle should be initiated, based on the `GCTimeRatio`. With this change, the benchmark attached to the ticket now completes in ~13 GC, a significant improvement compared to the >1000 GC observed previously.

Test: tier1-3

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

Commit messages:
 - s1-gc-time-ratio

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

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

From amitkumar at openjdk.org  Thu Jan  2 06:54:37 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 2 Jan 2025 06:54:37 GMT
Subject: RFR: 8345374: Ubsan: runtime error: division by zero
In-Reply-To: <zhB3t1eDrmm2hgi42U6sYXhBm1zTtvYCjr3gKZbrEe4=.ab63227b-8365-4841-9649-591fcd63a487@github.com>
References: <zhB3t1eDrmm2hgi42U6sYXhBm1zTtvYCjr3gKZbrEe4=.ab63227b-8365-4841-9649-591fcd63a487@github.com>
Message-ID: <HagOgTDxiorFi25BFv4VdH3L5pWVT3GlppAh-ER83LQ=.16bd2a89-e7dd-4404-9c5d-44c88c81080d@github.com>

On Mon, 30 Dec 2024 01:07:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to G1HeapSizingPolicy to avoid a float division by
> zero when calculating the maximum desired capacity with a MaxHeapFreeRatio
> value of 100%.
> 
> Testing: mach5 tier1 with G1 and MaxHeapFreeRatio=100.

Marked as reviewed by amitkumar (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22893#pullrequestreview-2527088351

From kbarrett at openjdk.org  Thu Jan  2 08:14:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Jan 2025 08:14:39 GMT
Subject: RFR: 8345374: Ubsan: runtime error: division by zero
In-Reply-To: <5J21YcGO5FJukhpN1W3G1dYu1KQudSVANgR2jUTF6JI=.4a46b4cf-dea2-473a-a036-a29004b722e9@github.com>
References: <zhB3t1eDrmm2hgi42U6sYXhBm1zTtvYCjr3gKZbrEe4=.ab63227b-8365-4841-9649-591fcd63a487@github.com>
 <5J21YcGO5FJukhpN1W3G1dYu1KQudSVANgR2jUTF6JI=.4a46b4cf-dea2-473a-a036-a29004b722e9@github.com>
Message-ID: <Ayf1A3KDVCycu8zvj5mtlMTLwiDFYq0U8tXl7oHkvBY=.433f630e-d389-4de3-bff6-759590c575ff@github.com>

On Tue, 31 Dec 2024 06:55:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review this change to G1HeapSizingPolicy to avoid a float division by
>> zero when calculating the maximum desired capacity with a MaxHeapFreeRatio
>> value of 100%.
>> 
>> Testing: mach5 tier1 with G1 and MaxHeapFreeRatio=100.
>
> Looks alright, but I think the title needs to be changed to match the one on the tracker

Thanks for reviews @TheShermanTanker , @albertnetymk , and @offamitkumar

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

PR Comment: https://git.openjdk.org/jdk/pull/22893#issuecomment-2567406190

From kbarrett at openjdk.org  Thu Jan  2 08:14:40 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Jan 2025 08:14:40 GMT
Subject: Integrated: 8345374: Ubsan: runtime error: division by zero
In-Reply-To: <zhB3t1eDrmm2hgi42U6sYXhBm1zTtvYCjr3gKZbrEe4=.ab63227b-8365-4841-9649-591fcd63a487@github.com>
References: <zhB3t1eDrmm2hgi42U6sYXhBm1zTtvYCjr3gKZbrEe4=.ab63227b-8365-4841-9649-591fcd63a487@github.com>
Message-ID: <yNhNhHeY-_MXgwTL352mqHoSmiG0pAxMWdF3Li2FN4I=.d873f273-5022-41c8-a07e-fb40ce4fa209@github.com>

On Mon, 30 Dec 2024 01:07:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to G1HeapSizingPolicy to avoid a float division by
> zero when calculating the maximum desired capacity with a MaxHeapFreeRatio
> value of 100%.
> 
> Testing: mach5 tier1 with G1 and MaxHeapFreeRatio=100.

This pull request has now been integrated.

Changeset: a87bc7e4
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a87bc7e4f0e797a108f447a1c9801abe39b700da
Stats:     8 lines in 1 file changed: 8 ins; 0 del; 0 mod

8345374: Ubsan: runtime error: division by zero

Reviewed-by: jwaters, ayang, amitkumar

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

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

From zgu at openjdk.org  Thu Jan  2 16:22:35 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 2 Jan 2025 16:22:35 GMT
Subject: RFR: 8346569: Shenandoah: Worker initializes
 ShenandoahThreadLocalData twice results in memory leak
In-Reply-To: <CIH8Ty37pKj53G8mQB-I26QjEHCgzSnNEJEfUgws1rM=.ea1aabfe-87af-4af7-bcdb-8c883d1dc76e@github.com>
References: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
 <CIH8Ty37pKj53G8mQB-I26QjEHCgzSnNEJEfUgws1rM=.ea1aabfe-87af-4af7-bcdb-8c883d1dc76e@github.com>
Message-ID: <SX8oSg27vu-dtAO8YPXxspNOcvYHbCkoTA_4Zp2mzXw=.27416f6b-3f45-4cf0-8d09-0621bb9d9c63@github.com>

On Thu, 19 Dec 2024 23:33:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Good catch! How'd you find this?

Thank you for the review. I have a script to capture allocations that have not seen before, I guess it is largely obsoleted by --enable-lsan.

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

PR Comment: https://git.openjdk.org/jdk/pull/22812#issuecomment-2568026495

From zgu at openjdk.org  Thu Jan  2 16:22:36 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 2 Jan 2025 16:22:36 GMT
Subject: RFR: 8346569: Shenandoah: Worker initializes
 ShenandoahThreadLocalData twice results in memory leak
In-Reply-To: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
References: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
Message-ID: <_g_TssIoBU2kwwm1XvAO-4noeadthqn1pPuVnNtW8jg=.dfec6482-ce98-4f8b-9e1b-c56a195cd309@github.com>

On Wed, 18 Dec 2024 14:46:57 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Worker thread initializes ShenandoahThreadLocalData twice, from Thread's constructor and ShenandoahWorkerThreads::on_create_worker(), that results in leaking ShenandoahEvacuationStats.

Can I have a (R)eview? @rkennke  and @shipilev?

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

PR Comment: https://git.openjdk.org/jdk/pull/22812#issuecomment-2568028950

From zgu at openjdk.org  Fri Jan  3 21:48:47 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 3 Jan 2025 21:48:47 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v4]
In-Reply-To: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
Message-ID: <QVPozXe1wyqYAfNRsXstws1NN8JCML5iBuDP4styP1E=.680fec3f-976d-4364-9db8-72d1e09fa756@github.com>

> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
> 
> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.

Zhengyu Gu 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:

 - Adopt latest PartialArrayStats changes
 - Merge branch 'master' into JDK-8339668
 - Merge branch 'master' into JDK-8339668
 - @tschatzl's ScannerTask changes
 - @tschatzl's comment
 - v8
 - v7
 - v6
 - v5
 - v4
 - ... and 5 more: https://git.openjdk.org/jdk/compare/37e5a031...0ed1a358

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21089/files
  - new: https://git.openjdk.org/jdk/pull/21089/files/fd756b3b..0ed1a358

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

  Stats: 832172 lines in 10732 files changed: 537899 ins; 230171 del; 64102 mod
  Patch: https://git.openjdk.org/jdk/pull/21089.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21089/head:pull/21089

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

From shade at openjdk.org  Mon Jan  6 09:57:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Jan 2025 09:57:35 GMT
Subject: RFR: 8346569: Shenandoah: Worker initializes
 ShenandoahThreadLocalData twice results in memory leak
In-Reply-To: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
References: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
Message-ID: <EQePP7IMgiB-gtTsUkcca7V7latdp4AleHUM8NvSOnw=.940a4e9e-a4b5-4d0a-a85a-1457a93259c4@github.com>

On Wed, 18 Dec 2024 14:46:57 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Worker thread initializes ShenandoahThreadLocalData twice, from Thread's constructor and ShenandoahWorkerThreads::on_create_worker(), that results in leaking ShenandoahEvacuationStats.

This makes sense, thanks. I see that in all other implementations, `BarrierSet` is responsible for creating thread-local data. AFAICS, this only becomes a problem when we run with generational mode that leaks `ShenandoahEvacuationStats`.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22812#pullrequestreview-2531783206

From zgu at openjdk.org  Mon Jan  6 13:47:42 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 6 Jan 2025 13:47:42 GMT
Subject: RFR: 8346569: Shenandoah: Worker initializes
 ShenandoahThreadLocalData twice results in memory leak
In-Reply-To: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
References: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
Message-ID: <5yrh2oRRSs-L4QZTgyFUTxd-jS0hDSkgWp-Uke5Cg4U=.41fadf56-e372-4b9d-a966-f4803fb6a235@github.com>

On Wed, 18 Dec 2024 14:46:57 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Worker thread initializes ShenandoahThreadLocalData twice, from Thread's constructor and ShenandoahWorkerThreads::on_create_worker(), that results in leaking ShenandoahEvacuationStats.

Thanks, @shipilev

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

PR Comment: https://git.openjdk.org/jdk/pull/22812#issuecomment-2573140414

From zgu at openjdk.org  Mon Jan  6 13:47:42 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 6 Jan 2025 13:47:42 GMT
Subject: Integrated: 8346569: Shenandoah: Worker initializes
 ShenandoahThreadLocalData twice results in memory leak
In-Reply-To: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
References: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
Message-ID: <-O5aGBTWtR__shbWdwHgYg-vWEmktBh59kxQhss9O88=.4e238976-5e83-4fb1-8b3e-5c28f7b2340f@github.com>

On Wed, 18 Dec 2024 14:46:57 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Worker thread initializes ShenandoahThreadLocalData twice, from Thread's constructor and ShenandoahWorkerThreads::on_create_worker(), that results in leaking ShenandoahEvacuationStats.

This pull request has now been integrated.

Changeset: dfaa8916
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfaa89162a35acd20b1ed35e147f9626a181510a
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8346569: Shenandoah: Worker initializes ShenandoahThreadLocalData twice results in memory leak

Reviewed-by: wkemper, shade

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

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

From gli at openjdk.org  Mon Jan  6 14:17:37 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 6 Jan 2025 14:17:37 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC
In-Reply-To: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
Message-ID: <EgnZpeIlTx7KSUAAY-ONihE0Dvyd_d5gXbCNwEY5jMU=.fe41dbba-a334-416e-a5e9-41cbd7db0cd4@github.com>

On Thu, 2 Jan 2025 06:30:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR introduces a new strategy to determine whether an allocation should be attempted in the old generation or if a GC cycle should be initiated, based on the `GCTimeRatio`. With this change, the benchmark attached to the ticket now completes in ~13 GC, a significant improvement compared to the >1000 GC observed previously.
> 
> Test: tier1-3

Nice improvement.

src/hotspot/share/gc/serial/defNewGeneration.hpp line 53:

> 51: class DefNewGeneration: public Generation {
> 52:   friend class VMStructs;
> 53:   friend class SerialHeap;

Not really know whether it is a good way. Maybe we can export  a method `DefNewGeneration::gc_timer`.

src/hotspot/share/gc/serial/serialHeap.cpp line 334:

> 332: 
> 333:       bool first_only = !should_try_older_generation_allocation(size)
> 334:                      && is_long_enough_from_prev_gc_pause_end();

Is the `first_only` actually `young_only`? It means that the allocation is only attempted in young generation?

src/hotspot/share/gc/serial/serialHeap.cpp line 643:

> 641:   Ticks prev_gc_pause_end;
> 642:   Tickspan gc_pause;
> 643:   if (full_gc_pause_end < young_gc_pause_end ) {

A unnecessary space after `young_gc_pause_end`.

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

Changes requested by gli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22899#pullrequestreview-2532209941
PR Review Comment: https://git.openjdk.org/jdk/pull/22899#discussion_r1904201771
PR Review Comment: https://git.openjdk.org/jdk/pull/22899#discussion_r1904191931
PR Review Comment: https://git.openjdk.org/jdk/pull/22899#discussion_r1904196305

From ayang at openjdk.org  Mon Jan  6 14:36:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 Jan 2025 14:36:23 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC [v2]
In-Reply-To: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
Message-ID: <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>

> This PR introduces a new strategy to determine whether an allocation should be attempted in the old generation or if a GC cycle should be initiated, based on the `GCTimeRatio`. With this change, the benchmark attached to the ticket now completes in ~13 GC, a significant improvement compared to the >1000 GC observed previously.
> 
> 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 s1-gc-time-ratio
 - s1-gc-time-ratio

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22899/files
  - new: https://git.openjdk.org/jdk/pull/22899/files/ee6300d7..52aa4ce4

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

  Stats: 1173 lines in 32 files changed: 31 ins; 1082 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/22899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22899/head:pull/22899

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

From ayang at openjdk.org  Mon Jan  6 14:40:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 Jan 2025 14:40:36 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC [v2]
In-Reply-To: <EgnZpeIlTx7KSUAAY-ONihE0Dvyd_d5gXbCNwEY5jMU=.fe41dbba-a334-416e-a5e9-41cbd7db0cd4@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
 <EgnZpeIlTx7KSUAAY-ONihE0Dvyd_d5gXbCNwEY5jMU=.fe41dbba-a334-416e-a5e9-41cbd7db0cd4@github.com>
Message-ID: <sApo92xewcqIhcPByYJiNP0BI9VYkFLIPMbKuHf6LSk=.31adce6a-7a76-4790-8ddf-ba5817d2978e@github.com>

On Mon, 6 Jan 2025 14:05:04 GMT, Guoxiong Li <gli 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 s1-gc-time-ratio
>>  - s1-gc-time-ratio
>
> src/hotspot/share/gc/serial/serialHeap.cpp line 334:
> 
>> 332: 
>> 333:       bool first_only = !should_try_older_generation_allocation(size)
>> 334:                      && is_long_enough_from_prev_gc_pause_end();
> 
> Is the `first_only` actually `young_only`? It means that the allocation is only attempted in young generation?

That's true. I believe Serial used to support >2 generations, so some generic names are left as is. Fixing it requires updating in multiple places, such as the method name `older_generation`, arg in `attempt_allocation`, etc. How about we do that invasive but pure refactoring in its own PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22899#discussion_r1904230427

From wkemper at openjdk.org  Mon Jan  6 18:08:08 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 6 Jan 2025 18:08:08 GMT
Subject: [jdk24] RFR: 8345970: pthread_getcpuclockid related crashes in
 shenandoah tests
Message-ID: <3queiTTYxaqjTtFWIMIQ6AMERNOr4BF4iLpp_5iVvRs=.506092ae-2458-4e41-97af-4e90630456fb@github.com>

Clean backport. Fixes acute issue with musl libc (used by Alpine Linux).

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

Commit messages:
 - Backport 2ce53e88481659734bc5424c643c5e31c116bc5d

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

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

From shade at openjdk.org  Mon Jan  6 18:19:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Jan 2025 18:19:40 GMT
Subject: [jdk24] RFR: 8345970: pthread_getcpuclockid related crashes in
 shenandoah tests
In-Reply-To: <3queiTTYxaqjTtFWIMIQ6AMERNOr4BF4iLpp_5iVvRs=.506092ae-2458-4e41-97af-4e90630456fb@github.com>
References: <3queiTTYxaqjTtFWIMIQ6AMERNOr4BF4iLpp_5iVvRs=.506092ae-2458-4e41-97af-4e90630456fb@github.com>
Message-ID: <drLKOzc6XpzYYAtZMayIEE4TW2ulZWoktq3BFMRJwxc=.bb68b4cb-d31f-4eb8-8bed-e2f5e69f2478@github.com>

On Mon, 6 Jan 2025 18:03:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes acute issue with musl libc (used by Alpine Linux).

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22933#pullrequestreview-2532708736

From wkemper at openjdk.org  Mon Jan  6 18:27:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 6 Jan 2025 18:27:41 GMT
Subject: [jdk24] Integrated: 8345970: pthread_getcpuclockid related crashes in
 shenandoah tests
In-Reply-To: <3queiTTYxaqjTtFWIMIQ6AMERNOr4BF4iLpp_5iVvRs=.506092ae-2458-4e41-97af-4e90630456fb@github.com>
References: <3queiTTYxaqjTtFWIMIQ6AMERNOr4BF4iLpp_5iVvRs=.506092ae-2458-4e41-97af-4e90630456fb@github.com>
Message-ID: <Rn6hafurFdabvqyK-VNO1J8HcDlD450nffo1csg-1yc=.924e873e-4bea-4e4e-a7bc-2993a6cf6dfd@github.com>

On Mon, 6 Jan 2025 18:03:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes acute issue with musl libc (used by Alpine Linux).

This pull request has now been integrated.

Changeset: cc7c293b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc7c293bce8a564943606dbbcad64db96909d68a
Stats:     18 lines in 4 files changed: 15 ins; 3 del; 0 mod

8345970: pthread_getcpuclockid related crashes in shenandoah tests

Reviewed-by: shade
Backport-of: 2ce53e88481659734bc5424c643c5e31c116bc5d

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

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

From kdnilsen at openjdk.org  Mon Jan  6 19:02:35 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 6 Jan 2025 19:02:35 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
In-Reply-To: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
Message-ID: <dFAs7Xerr7yKrXloEFu6DXECSEZiCcPn2Ugjpqqj9U0=.c116a2dd-636d-42e0-8df8-338ed976db33@github.com>

On Wed, 11 Dec 2024 19:08:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
> 
> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
> 
> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.

Thanks.  Looks very clean for how significant the change is in behavior...

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

Marked as reviewed by kdnilsen (Author).

PR Review: https://git.openjdk.org/jdk/pull/22688#pullrequestreview-2532779642

From duke at openjdk.org  Mon Jan  6 20:11:43 2025
From: duke at openjdk.org (duke)
Date: Mon, 6 Jan 2025 20:11:43 GMT
Subject: Withdrawn: 8343658: Parallel: Implement block_start for Young
 generation
In-Reply-To: <d32zlxIzcyDMl5TPtsewxAKYlmRlJs6qVgdeg57FMjw=.7874e920-7274-4444-948b-ecb4663f6d2d@github.com>
References: <d32zlxIzcyDMl5TPtsewxAKYlmRlJs6qVgdeg57FMjw=.7874e920-7274-4444-948b-ecb4663f6d2d@github.com>
Message-ID: <ovDLO5ikne-DEAoK5U5XaZ9dDAgBVc-2RssxbmHqIzY=.09ec5f50-3689-4a0c-b2d5-2c6ec75d3333@github.com>

On Wed, 6 Nov 2024 08:04:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple block_start implementation for Parallel young-gen. Related to https://github.com/openjdk/jdk/pull/21870
> 
> Test: tier1-3

This pull request has been closed without being integrated.

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

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

From gli at openjdk.org  Tue Jan  7 06:56:34 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 7 Jan 2025 06:56:34 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC [v2]
In-Reply-To: <sApo92xewcqIhcPByYJiNP0BI9VYkFLIPMbKuHf6LSk=.31adce6a-7a76-4790-8ddf-ba5817d2978e@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
 <EgnZpeIlTx7KSUAAY-ONihE0Dvyd_d5gXbCNwEY5jMU=.fe41dbba-a334-416e-a5e9-41cbd7db0cd4@github.com>
 <sApo92xewcqIhcPByYJiNP0BI9VYkFLIPMbKuHf6LSk=.31adce6a-7a76-4790-8ddf-ba5817d2978e@github.com>
Message-ID: <28lTO6UU1Ro2zUtCYj5Fwnw_4W0JLlnkEsGBVTfP55Q=.32a8761d-4ca5-4b00-8b1b-c71d288600a5@github.com>

On Mon, 6 Jan 2025 14:37:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/serialHeap.cpp line 334:
>> 
>>> 332: 
>>> 333:       bool first_only = !should_try_older_generation_allocation(size)
>>> 334:                      && is_long_enough_from_prev_gc_pause_end();
>> 
>> Is the `first_only` actually `young_only`? It means that the allocation is only attempted in young generation?
>
> That's true. I believe Serial used to support >2 generations, so some generic names are left as is. Fixing it requires updating in multiple places, such as the method name `older_generation`, arg in `attempt_allocation`, etc. How about we do that invasive but pure refactoring in its own PR?

Yes, such refactoring should be finished in other issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22899#discussion_r1904984586

From gli at openjdk.org  Tue Jan  7 07:08:35 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 7 Jan 2025 07:08:35 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC [v2]
In-Reply-To: <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
 <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>
Message-ID: <7v0-msW0bLb0qqi1dPLZeCWJH1yRkQ6Wi2tS3eNG2YQ=.12c38d9c-5de0-4f37-a7bb-df253a620f8a@github.com>

On Mon, 6 Jan 2025 14:36:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR introduces a new strategy to determine whether an allocation should be attempted in the old generation or if a GC cycle should be initiated, based on the `GCTimeRatio`. With this change, the benchmark attached to the ticket now completes in ~13 GC, a significant improvement compared to the >1000 GC observed previously.
>> 
>> 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 s1-gc-time-ratio
>  - s1-gc-time-ratio

Looks good.

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

Marked as reviewed by gli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22899#pullrequestreview-2533524913

From ayang at openjdk.org  Tue Jan  7 08:53:47 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Jan 2025 08:53:47 GMT
Subject: RFR: 8343658: Parallel: Implement block_start for Young generation
In-Reply-To: <d32zlxIzcyDMl5TPtsewxAKYlmRlJs6qVgdeg57FMjw=.7874e920-7274-4444-948b-ecb4663f6d2d@github.com>
References: <d32zlxIzcyDMl5TPtsewxAKYlmRlJs6qVgdeg57FMjw=.7874e920-7274-4444-948b-ecb4663f6d2d@github.com>
Message-ID: <kHVOK4DrdbWxBEYt5Jq0aUA5eF8Xf20o_Fzm5YKAVvE=.a35e2bec-6585-457f-bf36-a098968fe3ca@github.com>

On Wed, 6 Nov 2024 08:04:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple block_start implementation for Parallel young-gen. Related to https://github.com/openjdk/jdk/pull/21870
> 
> Test: tier1-3

@simonis My intention was simply to align Parallel with the existing implementations in Serial and G1, thereby removing the oddly structured `DebuggingContext` code.

While it?s possible to invest additional effort in object iteration to make failure-reporting more robust, it?s worth noting that the default GCs (Serial and G1) haven?t, to my knowledge, required such measures. Therefore, I wonder if we might be overthinking this without a specific, concrete need.

If you still think this is a step in the wrong direction, I will close the corresponding ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/21919#issuecomment-2574718495

From ayang at openjdk.org  Tue Jan  7 08:54:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Jan 2025 08:54:23 GMT
Subject: RFR: 8347094: Inline CollectedHeap::increment_total_full_collections
Message-ID: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>

Trivial inlining a method to its sole caller.

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

Commit messages:
 - trivial

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

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

From stefank at openjdk.org  Tue Jan  7 11:59:34 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 7 Jan 2025 11:59:34 GMT
Subject: RFR: 8347094: Inline
 CollectedHeap::increment_total_full_collections
In-Reply-To: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
References: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
Message-ID: <3y5lqLyLoBVQ1mNdfcbC5f7wNRLsz4sJmUYBxMlorwE=.f534955a-0cdc-4d20-8138-de967d94c3e2@github.com>

On Tue, 7 Jan 2025 08:48:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its sole caller.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22940#pullrequestreview-2534154583

From eosterlund at openjdk.org  Tue Jan  7 12:05:43 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 7 Jan 2025 12:05:43 GMT
Subject: RFR: 8347094: Inline
 CollectedHeap::increment_total_full_collections
In-Reply-To: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
References: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
Message-ID: <NX68T3gVeasIiSEbf-VWgKlin9U7Xn65AV_BW-SRWUY=.4dbb8ff2-2247-4355-b79a-cc6a82d360ab@github.com>

On Tue, 7 Jan 2025 08:48:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its sole caller.

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22940#pullrequestreview-2534167170

From simonis at openjdk.org  Tue Jan  7 16:07:42 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 7 Jan 2025 16:07:42 GMT
Subject: RFR: 8343658: Parallel: Implement block_start for Young generation
In-Reply-To: <kHVOK4DrdbWxBEYt5Jq0aUA5eF8Xf20o_Fzm5YKAVvE=.a35e2bec-6585-457f-bf36-a098968fe3ca@github.com>
References: <d32zlxIzcyDMl5TPtsewxAKYlmRlJs6qVgdeg57FMjw=.7874e920-7274-4444-948b-ecb4663f6d2d@github.com>
 <kHVOK4DrdbWxBEYt5Jq0aUA5eF8Xf20o_Fzm5YKAVvE=.a35e2bec-6585-457f-bf36-a098968fe3ca@github.com>
Message-ID: <L12JnO40Imb7Ml2v_meOXuz39CuS2G1IAJDy1hSEtk4=.5b10e0e6-c494-41e3-9154-e424ed0ac7bd@github.com>

On Tue, 7 Jan 2025 08:51:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple block_start implementation for Parallel young-gen. Related to https://github.com/openjdk/jdk/pull/21870
>> 
>> Test: tier1-3
>
> @simonis My intention was simply to align Parallel with the existing implementations in Serial and G1, thereby removing the oddly structured `DebuggingContext` code.
> 
> While it?s possible to invest additional effort in object iteration to make failure-reporting more robust, it?s worth noting that the default GCs (Serial and G1) haven?t, to my knowledge, required such measures. Therefore, I wonder if we might be overthinking this without a specific, concrete need.
> 
> If you still think this is a step in the wrong direction, I will close the corresponding ticket.

@albertnetymk, I will not veto if you want to proceed but as I've already wrote, the current implementation for Serial is definitely wrong and can lead to secondary crashes during error reporting (which I regularly see in hs_err files) and even wrong, to infinite loops in the worst case. I haven't analyzed the G1 code yet because it is more complex, but I'm pretty sure it is also wrong if called at arbitrary places during VMError reporting (e.g. it depends on `G1HeapRegion::_parsable_bottom` being set correctly which isn't necessarily the case if the VM crashes). 

If you proceed with this PR, I suggest to at least use [`LocationPrinter::is_valid_obj()`](https://github.com/openjdk/jdk/blob/ac82a8f89c7066fb1d379b12bcfd68053cb39ba4/src/hotspot/share/gc/shared/locationPrinter.cpp#L33) which internally uses [`Klass::is_valid()`](https://github.com/openjdk/jdk/blob/ac82a8f89c7066fb1d379b12bcfd68053cb39ba4/src/hotspot/share/oops/klass.cpp#L1038) to check the validity of an oop in `MutableSpace::block_start()` instead of just using `cast_to_oop()` and asserting `oopDesc::is_oop()`. This will give us at least some safety belts. Also, if you proceed with this PR, please update the Serial implementation to use `LocationPrinter::is_valid_obj()` as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/21919#issuecomment-2575665010

From shade at openjdk.org  Tue Jan  7 18:13:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Jan 2025 18:13:12 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
Message-ID: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>

One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.

The solution is cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.

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

Commit messages:
 - Fix

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

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

From shade at openjdk.org  Tue Jan  7 18:13:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Jan 2025 18:13:12 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
In-Reply-To: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
Message-ID: <iIWWaUyV7vbqbG2W31p5eCRy1fr2hAQBe-Hk-lPQ1pI=.ee6875cd-4620-410d-9f4a-9b68e406205d@github.com>

On Tue, 7 Jan 2025 18:08:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.
> 
> The solution is cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.

On my M1, the test now configures to much more reasonable heap size.


# Before
0s: Using 7 workers, each allocating: ~936M

# After
0s: Using 10 workers, each allocating: ~81M

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

PR Comment: https://git.openjdk.org/jdk/pull/22954#issuecomment-2575932718

From gli at openjdk.org  Wed Jan  8 06:46:36 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 8 Jan 2025 06:46:36 GMT
Subject: RFR: 8347094: Inline
 CollectedHeap::increment_total_full_collections
In-Reply-To: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
References: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
Message-ID: <g1uNCRf3vk_Z4DUrTeBs3yiVGdXYvniE0qtjp1CJD-I=.5e13c8cf-77fd-4672-aaea-22fb0f26d3a0@github.com>

On Tue, 7 Jan 2025 08:48:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its sole caller.

Marked as reviewed by gli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22940#pullrequestreview-2536137690

From gli at openjdk.org  Wed Jan  8 07:43:35 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 8 Jan 2025 07:43:35 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
In-Reply-To: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
Message-ID: <eoo6ILHxiOfQ3xwo03G-9xbwOWnBi8FVbL3HzCeorNQ=.88bc98bf-805c-4a5f-ba75-2ccd3438e75e@github.com>

On Tue, 7 Jan 2025 18:08:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.
> 
> I think the solution is to cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.

test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java line 84:

> 82: 
> 83:         // Figure out suitable number of workers (~1 per 100M).
> 84:         int allocationChunk = (int) Math.ceil((double) allocationSize * 100 / M);

If we want to use one worker per 100M, should the equation be `allocationSize / (100 * M)`? Did I miss anything?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22954#discussion_r1906618799

From aboldtch at openjdk.org  Wed Jan  8 08:21:34 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 8 Jan 2025 08:21:34 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
In-Reply-To: <eoo6ILHxiOfQ3xwo03G-9xbwOWnBi8FVbL3HzCeorNQ=.88bc98bf-805c-4a5f-ba75-2ccd3438e75e@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
 <eoo6ILHxiOfQ3xwo03G-9xbwOWnBi8FVbL3HzCeorNQ=.88bc98bf-805c-4a5f-ba75-2ccd3438e75e@github.com>
Message-ID: <iUBoO9-KbGFtWyUytkhyXxukSeoXLFSw5f-pX9NSaFk=.ada34c21-e6b8-4329-a738-293ab72cdffc@github.com>

On Wed, 8 Jan 2025 07:41:22 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.
>> 
>> I think the solution is to cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.
>
> test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java line 84:
> 
>> 82: 
>> 83:         // Figure out suitable number of workers (~1 per 100M).
>> 84:         int allocationChunk = (int) Math.ceil((double) allocationSize * 100 / M);
> 
> If we want to use one worker per 100M, should the equation be `allocationSize / (100 * M)`? Did I miss anything?

Yes. It looked weird that he got 10 workers. This test should now always result in `min(8, num_procs)` workers. Especially since this uses `executeLimitedTestJava`, so it will not propagate flags. So I am not sure how we ever run this test with a different heap without editing the test file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22954#discussion_r1906708622

From lgxbslgx at gmail.com  Wed Jan  8 08:30:02 2025
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Wed, 8 Jan 2025 16:30:02 +0800
Subject: [Discussion] Serial GC: Expand young generation size
Message-ID: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>

Hi all,

Currently, the young generation in SerialGC can't be expanded now
and is always the initial young generation size. It is not a very big
problem generally.
But in some situations, like JDK-8333386 [1], it will crash the VM
(unnecessary OutOfMemoryError).

So I want to implement the feature to expand the young generation size
(absolutely, not exceeding the max young generation size).
What do you think about it? Any ideas will be appreciated.

Best Regards,
-- Guoxiong

Related links:
[1] https://bugs.openjdk.org/browse/JDK-8333386
[2] https://bugs.openjdk.org/browse/JDK-8335925
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250108/04e42676/attachment.htm>

From shade at openjdk.org  Wed Jan  8 09:20:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Jan 2025 09:20:16 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
 [v2]
In-Reply-To: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
Message-ID: <5Fu1wC8AtzoNWOIR6b6y4wt9MNLh6df2o9m_weuLEnI=.dd2423b5-0394-4a57-9559-d89cdca8d5cb@github.com>

> One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.
> 
> I think the solution is to cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.

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

  Fix math

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22954/files
  - new: https://git.openjdk.org/jdk/pull/22954/files/35e051ad..75eed4ed

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

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

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

From shade at openjdk.org  Wed Jan  8 09:20:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Jan 2025 09:20:16 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
 [v2]
In-Reply-To: <iUBoO9-KbGFtWyUytkhyXxukSeoXLFSw5f-pX9NSaFk=.ada34c21-e6b8-4329-a738-293ab72cdffc@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
 <eoo6ILHxiOfQ3xwo03G-9xbwOWnBi8FVbL3HzCeorNQ=.88bc98bf-805c-4a5f-ba75-2ccd3438e75e@github.com>
 <iUBoO9-KbGFtWyUytkhyXxukSeoXLFSw5f-pX9NSaFk=.ada34c21-e6b8-4329-a738-293ab72cdffc@github.com>
Message-ID: <00OyVsTrmwh3IUqWmD_WXrQpC8LQ5K5pRYhDKezqjfo=.8a34be18-d1ac-4c70-bc67-72669e22ba29@github.com>

On Wed, 8 Jan 2025 08:18:41 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java line 84:
>> 
>>> 82: 
>>> 83:         // Figure out suitable number of workers (~1 per 100M).
>>> 84:         int allocationChunk = (int) Math.ceil((double) allocationSize * 100 / M);
>> 
>> If we want to use one worker per 100M, should the equation be `allocationSize / (100 * M)`? Did I miss anything?
>
> Yes. It looked weird that he got 10 workers. This test should now always result in `min(8, num_procs)` workers. Especially since this uses `executeLimitedTestJava`, so it will not propagate flags. So I am not sure how we ever run this test with a different heap without editing the test file.

Well, "he" made a math mistake that Guixiong noticed. New calculation yields 9 workers on M1, because we take `ceil(0.8*Xmx)`:


0s: Using 9 workers, each allocating: ~91M
0s: Allocation size 858993459, allocation chunks: 9


Fixed in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22954#discussion_r1906859432

From ayang at openjdk.org  Wed Jan  8 09:49:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Jan 2025 09:49:44 GMT
Subject: RFR: 8347094: Inline
 CollectedHeap::increment_total_full_collections
In-Reply-To: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
References: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
Message-ID: <vaxFMCFY0YYCyARhGwoIQxgqXpIREwgyeP_ravu_Gyg=.4ea7fa25-4638-47ca-b478-c221c384c188@github.com>

On Tue, 7 Jan 2025 08:48:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its sole caller.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/22940#issuecomment-2577230627

From ayang at openjdk.org  Wed Jan  8 09:49:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Jan 2025 09:49:44 GMT
Subject: Integrated: 8347094: Inline
 CollectedHeap::increment_total_full_collections
In-Reply-To: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
References: <RITtrXwipb1z02pZxKeGqGfrwVvVNcC1AeOX8wWAeFU=.c8333d54-4de7-41e2-a506-376f510989ec@github.com>
Message-ID: <InMCTeB5BkBlKQEZ1q8uwM75s1yAYASETcy8VnGx0ZA=.cf61b4de-3038-4086-8ee6-72c7792f24a4@github.com>

On Tue, 7 Jan 2025 08:48:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its sole caller.

This pull request has now been integrated.

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

8347094: Inline CollectedHeap::increment_total_full_collections

Reviewed-by: stefank, eosterlund, gli

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

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

From ayang at openjdk.org  Wed Jan  8 10:07:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Jan 2025 10:07:40 GMT
Subject: RFR: 8343658: Parallel: Implement block_start for Young generation
In-Reply-To: <L12JnO40Imb7Ml2v_meOXuz39CuS2G1IAJDy1hSEtk4=.5b10e0e6-c494-41e3-9154-e424ed0ac7bd@github.com>
References: <d32zlxIzcyDMl5TPtsewxAKYlmRlJs6qVgdeg57FMjw=.7874e920-7274-4444-948b-ecb4663f6d2d@github.com>
 <kHVOK4DrdbWxBEYt5Jq0aUA5eF8Xf20o_Fzm5YKAVvE=.a35e2bec-6585-457f-bf36-a098968fe3ca@github.com>
 <L12JnO40Imb7Ml2v_meOXuz39CuS2G1IAJDy1hSEtk4=.5b10e0e6-c494-41e3-9154-e424ed0ac7bd@github.com>
Message-ID: <DsjZqSKtBP_9wf7mkhPajobhFo9dNFrAaL9iTrO0H1o=.e0e8fc95-0383-49f5-9860-b0359986cb68@github.com>

On Tue, 7 Jan 2025 16:04:45 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> the current implementation for Serial is definitely wrong and can lead to secondary crashes during error reporting (which I regularly see in hs_err files)

@simonis Can you create a bug/ticket for that secondary crash with repro info? That sounds like a real bug. (If not all necessary info/files are readily available, maybe you can collect them in the next occurrence.) Depending on how it goes with Serial, we can probably do sth similar in other GCs (e.g. Parallel).

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/21919#issuecomment-2577275582

From albert.m.yang at oracle.com  Wed Jan  8 10:27:39 2025
From: albert.m.yang at oracle.com (Albert Yang)
Date: Wed, 8 Jan 2025 10:27:39 +0000
Subject: [Discussion] Serial GC: Expand young generation size
In-Reply-To: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>
References: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>
Message-ID: <SA3PR10MB7022AB3FB889B4ABF2400E85D3122@SA3PR10MB7022.namprd10.prod.outlook.com>

Re https://bugs.openjdk.org/browse/JDK-8333386, I think your suggestion, "add the option `-XX:NewSize=65m`", is the way to go.

As for adding young-gen expansion support to Serial, it probably should have its own enhancement ticket.

I am currently working on placing from/to spaces before eden inside young-gen as part of Parallel heap-auto-sizing. I believe Serial can use the same layout (from/to/eden, instead of eden/from/to) to facilitate eden/young-gen expansion. My 2c.

/Albert

________________________________________
From: hotspot-gc-dev <hotspot-gc-dev-retn at openjdk.org> on behalf of Guoxiong Li <lgxbslgx at gmail.com>
Sent: Wednesday, January 8, 2025 09:30
To: hotspot-gc-dev at openjdk.org
Subject: [Discussion] Serial GC: Expand young generation size

Hi all,

Currently, the young generation in SerialGC can't be expanded now
and is always the initial young generation size. It is not a very big problem generally.
But in some situations, like JDK-8333386 [1], it will crash the VM (unnecessary OutOfMemoryError).

So I want to implement the feature to expand the young generation size
(absolutely, not exceeding the max young generation size).
What do you think about it? Any ideas will be appreciated.

Best Regards,
-- Guoxiong

Related links:
[1] https://bugs.openjdk.org/browse/JDK-8333386
[2] https://bugs.openjdk.org/browse/JDK-8335925


From shade at openjdk.org  Wed Jan  8 11:03:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Jan 2025 11:03:17 GMT
Subject: RFR: 8347256: Epsilon: Demote heap size and AlwaysPreTouch warnings to
 info level
Message-ID: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>

For Epsilon, we have added `log_warning` messages when heap size and AlwaysPreTouch configuration is not great with [JDK-8232051](https://bugs.openjdk.org/browse/JDK-8232051). Unfortunately, this means we print this warning all the time, even though users might not actually run into problems there, or when users tried to implement these suggestions and still decided to run against them.

I think we want to emit the suggestions in the normal GC log instead, so they are not printed all the time. Additionally, I moved the printing at the end of init logger, so it does not come in the middle of `gc,init` block.

Output before:


$ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
[0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
[0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
Hello!

$ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
[0.008s][info][gc] Using Epsilon
[0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
[0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
Hello!
[0.757s][info   ][gc     ] Heap: 1024M reserved, 129M (12.60%) committed, 23906K (2.28%) used


Output after:


$ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
Hello!

$ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
[0.009s][info][gc] Using Epsilon
[0.009s][info][gc] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
[0.009s][info][gc] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
Hello!
[0.753s][info][gc] Heap: 1024M reserved, 129M (12.60%) committed, 23908K (2.28%) used

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

Commit messages:
 - Leave it in epsilonInitLogger
 - Fix

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

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

From tschatzl at openjdk.org  Wed Jan  8 14:36:34 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Jan 2025 14:36:34 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
 [v2]
In-Reply-To: <5Fu1wC8AtzoNWOIR6b6y4wt9MNLh6df2o9m_weuLEnI=.dd2423b5-0394-4a57-9559-d89cdca8d5cb@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
 <5Fu1wC8AtzoNWOIR6b6y4wt9MNLh6df2o9m_weuLEnI=.dd2423b5-0394-4a57-9559-d89cdca8d5cb@github.com>
Message-ID: <MTAdgmcG2vElpR2AnrRGYbnuoGK6xGP8FSrD971Q1Sw=.da9b7ea6-2a22-496c-aa9c-ad2c69a90ba6@github.com>

On Wed, 8 Jan 2025 09:20:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.
>> 
>> I think the solution is to cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix math

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22954#pullrequestreview-2537314050

From tschatzl at openjdk.org  Wed Jan  8 15:03:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Jan 2025 15:03:35 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
 [v2]
In-Reply-To: <5Fu1wC8AtzoNWOIR6b6y4wt9MNLh6df2o9m_weuLEnI=.dd2423b5-0394-4a57-9559-d89cdca8d5cb@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
 <5Fu1wC8AtzoNWOIR6b6y4wt9MNLh6df2o9m_weuLEnI=.dd2423b5-0394-4a57-9559-d89cdca8d5cb@github.com>
Message-ID: <xCg1gS8rbN3FLwsFuo8D2TT_fS5hpZLd8SoBI6dAaLo=.43e21e89-000d-42b9-bd41-2d5b906bf0db@github.com>

On Wed, 8 Jan 2025 09:20:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.
>> 
>> I think the solution is to cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix math

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22954#pullrequestreview-2537386212

From gli at openjdk.org  Wed Jan  8 15:10:49 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 8 Jan 2025 15:10:49 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
 [v2]
In-Reply-To: <5Fu1wC8AtzoNWOIR6b6y4wt9MNLh6df2o9m_weuLEnI=.dd2423b5-0394-4a57-9559-d89cdca8d5cb@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
 <5Fu1wC8AtzoNWOIR6b6y4wt9MNLh6df2o9m_weuLEnI=.dd2423b5-0394-4a57-9559-d89cdca8d5cb@github.com>
Message-ID: <WbCFz9A1jZZ6ZMvhx_Nllpq2WK3vqRTbRF0uk2PGTVY=.e86395d6-317f-421b-b082-04dcf62db95d@github.com>

On Wed, 8 Jan 2025 09:20:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.
>> 
>> I think the solution is to cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix math

Marked as reviewed by gli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22954#pullrequestreview-2537417062

From tschatzl at openjdk.org  Wed Jan  8 15:52:37 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Jan 2025 15:52:37 GMT
Subject: RFR: 8347256: Epsilon: Demote heap size and AlwaysPreTouch
 warnings to info level
In-Reply-To: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>
References: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>
Message-ID: <L0zRMvlruXRbaBW_a7fq6bC2NEQOeTxQsdDYOjgxM5g=.713ff6cb-cf5c-4379-b1fc-0ba3a59d55c3@github.com>

On Wed, 8 Jan 2025 10:58:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For Epsilon, we have added `log_warning` messages when heap size and AlwaysPreTouch configuration is not great with [JDK-8232051](https://bugs.openjdk.org/browse/JDK-8232051). Unfortunately, this means we print this warning all the time, even though users might not actually run into problems there, or when users tried to implement these suggestions and still decided to run against them.
> 
> I think we want to emit the suggestions in the normal GC log instead, so they are not printed all the time. Additionally, I moved the printing at the end of init logger, so it does not come in the middle of `gc,init` block.
> 
> Output before:
> 
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
> [0.008s][info][gc] Using Epsilon
> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> [0.757s][info   ][gc     ] Heap: 1024M reserved, 129M (12.60%) committed, 23906K (2.28%) used
> 
> 
> Output after:
> 
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
> Hello!
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
> [0.009s][info][gc] Using Epsilon
> [0.009s][info][gc] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.009s][info][gc] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> [0.753s][info][gc] Heap: 1024M reserved, 129M (12.60%) committed, 23908K (2.28%) used

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22965#pullrequestreview-2537531580

From ysr at openjdk.org  Wed Jan  8 16:43:02 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 8 Jan 2025 16:43:02 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
In-Reply-To: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
Message-ID: <Oyg_xbxTPmgo5IaTwKpQsuLA6FINh04NMwn_1mZcZAE=.81a30c98-6742-404b-ae5e-743eaa278a3c@github.com>

On Wed, 11 Dec 2024 19:08:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
> 
> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
> 
> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.

Looks good... Left a few documentation request comments. I haven't fully wrapped my head around the correctness of this yet (sorry, slow start to the new year :-), and will go over it again and complete it a bit later today after I get to the office.

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1166:

> 1164:   }
> 1165: 
> 1166:   if (VerifyAfterGC) {

What are the conventions of when to use Verify{Before,After,During}GC on the one hand, vs ShenandoahVerify, G1Verify* etc., on the other?

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2650:

> 2648: bool ShenandoahHeap::is_gc_state(GCState state) const {
> 2649:   return _gc_state_changed ? _gc_state.is_set(state) : ShenandoahThreadLocalData::is_gc_state(state);
> 2650: }

This needs a documentation comment, please; e.g. why we check `_gc_state_changed` before we check the global state. Is the transition of the local and global states wrt the phase described in a comment somewhere else already?

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 371:

> 369: public:
> 370:   char gc_state() const;
> 371:   bool is_gc_state(GCState state) const;

Can you write a 1-line documentation comment for this method? It would make its implementation clearer. (See my comment in the method's implementation.)

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 374:

> 372: 
> 373:   // This copies the global gc state into a thread local variable for all threads.
> 374:   // It is primarily intended to support quick access at barriers. All threads are

Instead of "It ..." say "The thread local gc state ..."

src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 150:

> 148:     return 3;
> 149:   }
> 150:   if (heap->is_concurrent_mark_in_progress() || heap->is_concurrent_weak_root_in_progress() || heap->is_full_gc_in_progress()) {

naive question: where are the counters/encoding used?

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

PR Review: https://git.openjdk.org/jdk/pull/22688#pullrequestreview-2536114812
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1907457433
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1906544298
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1906551170
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1906548845
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1906541100

From ysr at openjdk.org  Wed Jan  8 16:43:02 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 8 Jan 2025 16:43:02 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
In-Reply-To: <Oyg_xbxTPmgo5IaTwKpQsuLA6FINh04NMwn_1mZcZAE=.81a30c98-6742-404b-ae5e-743eaa278a3c@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <Oyg_xbxTPmgo5IaTwKpQsuLA6FINh04NMwn_1mZcZAE=.81a30c98-6742-404b-ae5e-743eaa278a3c@github.com>
Message-ID: <K8uhajPJ1WXy48UBjyKZaAOhB3DLzB31-qhJeOumLZU=.e4980367-5fc1-4756-9ca9-ffe8470ad3b8@github.com>

On Wed, 8 Jan 2025 06:30:45 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
>> 
>> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
>> 
>> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2650:
> 
>> 2648: bool ShenandoahHeap::is_gc_state(GCState state) const {
>> 2649:   return _gc_state_changed ? _gc_state.is_set(state) : ShenandoahThreadLocalData::is_gc_state(state);
>> 2650: }
> 
> This needs a documentation comment, please; e.g. why we check `_gc_state_changed` before we check the global state. Is the transition of the local and global states wrt the phase described in a comment somewhere else already?

Or is this a common idiom used elsewhere as well, and already well-documented?

> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 371:
> 
>> 369: public:
>> 370:   char gc_state() const;
>> 371:   bool is_gc_state(GCState state) const;
> 
> Can you write a 1-line documentation comment for this method? It would make its implementation clearer. (See my comment in the method's implementation.)

(e.g. that, unlike comment at line 366, this must return the "right" value even at non-safepoints.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1907477306
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1906552223

From wkemper at openjdk.org  Wed Jan  8 20:28:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Jan 2025 20:28:25 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v3]
In-Reply-To: <ir7v8yCpyQhZC2CAz6q7JjQgjnYEHLwCM3oLPQN740w=.9e88f4ed-a264-40d7-85f2-1e80b3683b91@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
 <dM5MCVZSF9knRaGdmymF34oknNNnnG5BZyFHPtEvNIg=.0244a9d4-e242-45ce-b26a-1bad65f5f34a@github.com>
 <c7jTu7X5Lo8EpAlp1rywuDMhok7RnaQalgphByITXy4=.78d476a9-1ec3-49f7-ab79-3b5b01e79ea3@github.com>
 <ir7v8yCpyQhZC2CAz6q7JjQgjnYEHLwCM3oLPQN740w=.9e88f4ed-a264-40d7-85f2-1e80b3683b91@github.com>
Message-ID: <f2c7EM433O6AJ_mEQm3ZTSgF0BiQpYneeLWBS92kmjg=.2877e277-7a1f-4694-a04b-a6490254f2c1@github.com>

On Sat, 21 Dec 2024 01:48:10 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> The old cycle may be preempted by young collections, but it is only really _cancelled_ by global cycles or full GCs. Control thread will resume old marking, but this operates independently from young bitmap regions. I think we can reset young region bitmaps even when concurrent old marking is on going.
>
> I think we are taking about the same thing, old gen could be preempted by young gc and resumed after the cycle. I have seem crash from gc verification caused by this, an old gc was bootstrapped but it was preempted/canceled multiple times right after the old gc started, eventually caused a crash from verifier because it expected the object in young is marked. I will share the gc log on slack later.

That sounds like an issue with the verifier then? Once a young cycle is complete, nothing should depend on the state of the bitmaps for young regions (if, for no other reason, evacuation could have moved objects so that the bitmaps no longer represent the addresses of marked objects that were evacuated).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1907802968

From wkemper at openjdk.org  Wed Jan  8 20:41:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Jan 2025 20:41:47 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
In-Reply-To: <Oyg_xbxTPmgo5IaTwKpQsuLA6FINh04NMwn_1mZcZAE=.81a30c98-6742-404b-ae5e-743eaa278a3c@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <Oyg_xbxTPmgo5IaTwKpQsuLA6FINh04NMwn_1mZcZAE=.81a30c98-6742-404b-ae5e-743eaa278a3c@github.com>
Message-ID: <Y62Hr-GdjoZjy6PlMa-323dlHKgV5ApU8hdFLr9kUtw=.db679def-27ff-42f8-b03b-9c00d7a7804c@github.com>

On Wed, 8 Jan 2025 06:26:38 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
>> 
>> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
>> 
>> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 150:
> 
>> 148:     return 3;
>> 149:   }
>> 150:   if (heap->is_concurrent_mark_in_progress() || heap->is_concurrent_weak_root_in_progress() || heap->is_full_gc_in_progress()) {
> 
> naive question: where are the counters/encoding used?

They get put in `PerfData` variables. They also may be serialized in a log. The [Shenandoah Visualizer](https://github.com/openjdk/shenandoah-visualizer) is able to render them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1907839891

From wkemper at openjdk.org  Wed Jan  8 20:45:48 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Jan 2025 20:45:48 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
In-Reply-To: <Oyg_xbxTPmgo5IaTwKpQsuLA6FINh04NMwn_1mZcZAE=.81a30c98-6742-404b-ae5e-743eaa278a3c@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <Oyg_xbxTPmgo5IaTwKpQsuLA6FINh04NMwn_1mZcZAE=.81a30c98-6742-404b-ae5e-743eaa278a3c@github.com>
Message-ID: <rrM9dgDaceKJU-tSe0yyNiKy1qy1wfe5jtB9yIhNiJI=.8b755c4a-1ed1-451c-95aa-9f1ffefbc458@github.com>

On Wed, 8 Jan 2025 16:25:23 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
>> 
>> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
>> 
>> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1166:
> 
>> 1164:   }
>> 1165: 
>> 1166:   if (VerifyAfterGC) {
> 
> What are the conventions of when to use Verify{Before,After,During}GC on the one hand, vs ShenandoahVerify, G1Verify* etc., on the other?

I don't really think there is a convention. In this particular case, it was "verifying" before concurrent reference processing was complete, which could lead to erroneous verification failures.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1907844225

From kdnilsen at openjdk.org  Wed Jan  8 20:52:44 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 8 Jan 2025 20:52:44 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v3]
In-Reply-To: <OfmB9ehsC_CJI5Pv7JfEsyieZndfEPUa7wiDIz3PDpw=.5bfc80b3-11de-4af4-a095-55958b17da3d@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <OfmB9ehsC_CJI5Pv7JfEsyieZndfEPUa7wiDIz3PDpw=.5bfc80b3-11de-4af4-a095-55958b17da3d@github.com>
Message-ID: <Q0hgluLJUb5jeaz27fELFXYpDkgrFfcY9B6OufCtal8=.87af8e26-7ac8-4484-bf33-d9074af06f42@github.com>

On Mon, 30 Dec 2024 22:54:27 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
>> 
>> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
>> 
>> GenShen:
>> Before:
>> 
>> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
>> 
>> 
>> After:
>> 
>> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
>> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
>> 
>> 
>> Shenandoah:
>> Before:
>> 
>> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
>> 
>> After:
>> 
>> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
>> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
>> 
>> 
>> Additional changes:
>> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
>> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
>> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
>> * Clean up FullGC code, remove duplicate code.
>> 
>> ...
>
> Xiaolong Peng 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 17 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into reset-bitmap
>  - Address review comments
>  - Merge branch 'openjdk:master' into reset-bitmap
>  - Remove ShenandoahResetUpdateRegionStateClosure
>  - Always set_mark_incomplete when reset mark bitmap
>  - Fix
>  - Add comments
>  - fix
>  - Not reset_mark_bitmap after cycle when  is_concurrent_old_mark_in_progress or is_prepare_for_old_mark_in_progress
>  - Not invoke set_mark_incomplete when reset bitmap after cycle
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/82c2f771...f82fdfaa

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 242:

> 240:   // Instead of always reset before collect, some reset can be done after collect to save
> 241:   // the time before before the cycle so the cycle can be started as soon as possible.
> 242:   entry_reset_after_collect();

For comment, I would say: "Instead of always resetting immediately before the start of a new GC, we can often reset at the end of the previous GC.  This allows us to start the next GC cycle more quickly after a trigger condition is detected, reducing the likelihood that GC will degenerate."

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 592:

> 590:   // If it is old GC bootstrap cycle, always clear bitmap for global gen
> 591:   // to ensure bitmap for old gen is clear for old GC cycle after this.
> 592:   if (_do_old_gc_bootstrap) {

This may deserve a comment.  It seems we ought to clear the old-gen mark bitmap at the end of coalesce-and-fill.  But that does not allow us to avoid clearing old-gen mark bitmaps at start of bootstrap because when young-gen regions are promoted in place, the mark bitmap is preserved for those regions, and since they are considered old at the end of the GC cycle during which they were promoted, those bitmaps will not be cleared by op_reset_after_collect().  Is there a way to improve this behavior?

For example, in op_reset_after_collect(), maybe we should clear old-gen bitmaps also (at least for recently promoted in place regions) unless old marking is in process and/or mixed evacuations are in progress.

Maybe this can be tackled in a separate PR, but would be good to file JBS ticket now if there is agreement on the approach.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1907828996
PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1907845214

From kdnilsen at openjdk.org  Wed Jan  8 20:52:45 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 8 Jan 2025 20:52:45 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v3]
In-Reply-To: <f2c7EM433O6AJ_mEQm3ZTSgF0BiQpYneeLWBS92kmjg=.2877e277-7a1f-4694-a04b-a6490254f2c1@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
 <dM5MCVZSF9knRaGdmymF34oknNNnnG5BZyFHPtEvNIg=.0244a9d4-e242-45ce-b26a-1bad65f5f34a@github.com>
 <c7jTu7X5Lo8EpAlp1rywuDMhok7RnaQalgphByITXy4=.78d476a9-1ec3-49f7-ab79-3b5b01e79ea3@github.com>
 <ir7v8yCpyQhZC2CAz6q7JjQgjnYEHLwCM3oLPQN740w=.9e88f4ed-a264-40d7-85f2-1e80b3683b91@github.com>
 <f2c7EM433O6AJ_mEQm3ZTSgF0BiQpYneeLWBS92kmjg=.2877e277-7a1f-4694-a04b-a6490254f2c1@github.com>
Message-ID: <6kG3_NLd3D4G9fYnrmdKw-s25Fsmu1rLwOV_6eRDrfI=.cd23eb62-96b9-459f-a313-2d4ae7762284@github.com>

On Wed, 8 Jan 2025 20:15:30 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I think we are taking about the same thing, old gen could be preempted by young gc and resumed after the cycle. I have seem crash from gc verification caused by this, an old gc was bootstrapped but it was preempted/canceled multiple times right after the old gc started, eventually caused a crash from verifier because it expected the object in young is marked. I will share the gc log on slack later.
>
> That sounds like an issue with the verifier then? Once a young cycle is complete, nothing should depend on the state of the bitmaps for young regions (if, for no other reason, evacuation could have moved objects so that the bitmaps no longer represent the addresses of marked objects that were evacuated).

I agree with @earthling-amzn that we should be able to reset young-generation mark bitmap even if this is old_gc_bootstrap and even if old marking is in progress.  We should dive deeper to figure out the crash you observed.  It seems we don't fully understand the root cause.

I also suggest rewording the comment.  trigged?  (See other comments about increasing generality of this approach.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1907848997

From xpeng at openjdk.org  Wed Jan  8 21:40:59 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 8 Jan 2025 21:40:59 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v3]
In-Reply-To: <Q0hgluLJUb5jeaz27fELFXYpDkgrFfcY9B6OufCtal8=.87af8e26-7ac8-4484-bf33-d9074af06f42@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <OfmB9ehsC_CJI5Pv7JfEsyieZndfEPUa7wiDIz3PDpw=.5bfc80b3-11de-4af4-a095-55958b17da3d@github.com>
 <Q0hgluLJUb5jeaz27fELFXYpDkgrFfcY9B6OufCtal8=.87af8e26-7ac8-4484-bf33-d9074af06f42@github.com>
Message-ID: <a0X6VZa2qUKYeHmH9DxX-77dC8QFBveDIvDu-Cp94Zo=.d0315855-4b50-427f-8d65-cb80c0f0f89e@github.com>

On Wed, 8 Jan 2025 20:43:36 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Xiaolong Peng 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 17 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into reset-bitmap
>>  - Address review comments
>>  - Merge branch 'openjdk:master' into reset-bitmap
>>  - Remove ShenandoahResetUpdateRegionStateClosure
>>  - Always set_mark_incomplete when reset mark bitmap
>>  - Fix
>>  - Add comments
>>  - fix
>>  - Not reset_mark_bitmap after cycle when  is_concurrent_old_mark_in_progress or is_prepare_for_old_mark_in_progress
>>  - Not invoke set_mark_incomplete when reset bitmap after cycle
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/5c258fa2...f82fdfaa
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 592:
> 
>> 590:   // If it is old GC bootstrap cycle, always clear bitmap for global gen
>> 591:   // to ensure bitmap for old gen is clear for old GC cycle after this.
>> 592:   if (_do_old_gc_bootstrap) {
> 
> This may deserve a comment.  It seems we ought to clear the old-gen mark bitmap at the end of coalesce-and-fill.  But that does not allow us to avoid clearing old-gen mark bitmaps at start of bootstrap because when young-gen regions are promoted in place, the mark bitmap is preserved for those regions, and since they are considered old at the end of the GC cycle during which they were promoted, those bitmaps will not be cleared by op_reset_after_collect().  Is there a way to improve this behavior?
> 
> For example, in op_reset_after_collect(), maybe we should clear old-gen bitmaps also (at least for recently promoted in place regions) unless old marking is in process and/or mixed evacuations are in progress.
> 
> Maybe this can be tackled in a separate PR, but would be good to file JBS ticket now if there is agreement on the approach.

Yes, We can reset bimap of old region when there in place promotion and all old regions after coalesce-and-fill for old gen. 

Thanks Kelvin, I'll create a JBS ticket for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1907893752

From xpeng at openjdk.org  Wed Jan  8 22:58:30 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 8 Jan 2025 22:58:30 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v3]
In-Reply-To: <Q0hgluLJUb5jeaz27fELFXYpDkgrFfcY9B6OufCtal8=.87af8e26-7ac8-4484-bf33-d9074af06f42@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <OfmB9ehsC_CJI5Pv7JfEsyieZndfEPUa7wiDIz3PDpw=.5bfc80b3-11de-4af4-a095-55958b17da3d@github.com>
 <Q0hgluLJUb5jeaz27fELFXYpDkgrFfcY9B6OufCtal8=.87af8e26-7ac8-4484-bf33-d9074af06f42@github.com>
Message-ID: <kzuT2ioU_c8Q2R5YlluU8fyQ_sjinu9E-CVhDJlnLm0=.2d999edf-8473-499a-a731-349be7f4006f@github.com>

On Wed, 8 Jan 2025 20:30:38 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Xiaolong Peng 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 17 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into reset-bitmap
>>  - Address review comments
>>  - Merge branch 'openjdk:master' into reset-bitmap
>>  - Remove ShenandoahResetUpdateRegionStateClosure
>>  - Always set_mark_incomplete when reset mark bitmap
>>  - Fix
>>  - Add comments
>>  - fix
>>  - Not reset_mark_bitmap after cycle when  is_concurrent_old_mark_in_progress or is_prepare_for_old_mark_in_progress
>>  - Not invoke set_mark_incomplete when reset bitmap after cycle
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/099e4ed4...f82fdfaa
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 242:
> 
>> 240:   // Instead of always reset before collect, some reset can be done after collect to save
>> 241:   // the time before before the cycle so the cycle can be started as soon as possible.
>> 242:   entry_reset_after_collect();
> 
> For comment, I would say: "Instead of always resetting immediately before the start of a new GC, we can often reset at the end of the previous GC.  This allows us to start the next GC cycle more quickly after a trigger condition is detected, reducing the likelihood that GC will degenerate."

I'll update comments, thanks Kelvin!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1907947027

From wkemper at openjdk.org  Wed Jan  8 23:31:51 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Jan 2025 23:31:51 GMT
Subject: [jdk24] RFR: 8346737: GenShen: Generational memory pools should not
 report zero for maximum capacity
Message-ID: <npQ6aTvYAGkDIh0KoSyPOxUIFKtz2VCBewDkGlSG55k=.601ac51b-983a-4832-850a-d09dbba72c19@github.com>

Clean backport. Fixes many SA tests.

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

Commit messages:
 - Backport 249f141211c94afcce70d9d536d84e108e07b4e5

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

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

From kdnilsen at openjdk.org  Thu Jan  9 00:22:35 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 9 Jan 2025 00:22:35 GMT
Subject: [jdk24] RFR: 8346737: GenShen: Generational memory pools should
 not report zero for maximum capacity
In-Reply-To: <npQ6aTvYAGkDIh0KoSyPOxUIFKtz2VCBewDkGlSG55k=.601ac51b-983a-4832-850a-d09dbba72c19@github.com>
References: <npQ6aTvYAGkDIh0KoSyPOxUIFKtz2VCBewDkGlSG55k=.601ac51b-983a-4832-850a-d09dbba72c19@github.com>
Message-ID: <Wj3wMlLPBtLUOJnEU5jyFCK7oSHiAcKwvFpeAV5HrRo=.a70319a8-bf16-4427-bab1-f7d072621304@github.com>

On Wed, 8 Jan 2025 23:26:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes many SA tests.

Marked as reviewed by kdnilsen (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/22984#pullrequestreview-2538518161

From ysr at openjdk.org  Thu Jan  9 00:59:42 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 9 Jan 2025 00:59:42 GMT
Subject: [jdk24] RFR: 8346737: GenShen: Generational memory pools should
 not report zero for maximum capacity
In-Reply-To: <npQ6aTvYAGkDIh0KoSyPOxUIFKtz2VCBewDkGlSG55k=.601ac51b-983a-4832-850a-d09dbba72c19@github.com>
References: <npQ6aTvYAGkDIh0KoSyPOxUIFKtz2VCBewDkGlSG55k=.601ac51b-983a-4832-850a-d09dbba72c19@github.com>
Message-ID: <2SlOW_Bx_aU_KyYjRVjHmZcmkgp0M1qjNV29EULbdtk=.41d35bd0-7a53-43cb-89fb-7fa820a49538@github.com>

On Wed, 8 Jan 2025 23:26:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes many SA tests.

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22984#pullrequestreview-2538573609

From syan at openjdk.org  Thu Jan  9 03:56:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 Jan 2025 03:56:03 GMT
Subject: RFR: 8347279: Problemlist TestEvilSyncBug.java#generational
Message-ID: <3Ytom-NSY6xE6P0PerrVxrCd4lM3LqJ2LYkXSm0NG6c=.3c9b94cb-5c43-498f-b80e-557aa61e2635@github.com>

Hi all,
Test gc/shenandoah/TestEvilSyncBug.java#generational was observed times out on a lot of platforms (various Linux and Windows too) several times recently. Should we Problemlist this test before the failure root cause been fixed.

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

Commit messages:
 - 8347279: Problemlist TestEvilSyncBug.java#generational

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

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

From shade at openjdk.org  Thu Jan  9 09:51:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Jan 2025 09:51:40 GMT
Subject: RFR: 8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed
 [v2]
In-Reply-To: <5Fu1wC8AtzoNWOIR6b6y4wt9MNLh6df2o9m_weuLEnI=.dd2423b5-0394-4a57-9559-d89cdca8d5cb@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
 <5Fu1wC8AtzoNWOIR6b6y4wt9MNLh6df2o9m_weuLEnI=.dd2423b5-0394-4a57-9559-d89cdca8d5cb@github.com>
Message-ID: <ya9zNLqNFDvJQX64Kih9uU6g9fStsuCbhZLpKxcVvnE=.2df4bf27-b4c0-4e0d-a7fa-bd25f5343cd4@github.com>

On Wed, 8 Jan 2025 09:20:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.
>> 
>> I think the solution is to cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix math

Thanks for reviews! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22954#issuecomment-2579619953

From shade at openjdk.org  Thu Jan  9 09:51:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Jan 2025 09:51:41 GMT
Subject: Integrated: 8347126: gc/stress/TestStressG1Uncommit.java gets
 OOM-killed
In-Reply-To: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
References: <J3_tewSVzq2hnaEKzc58uFYygdGlwXP_fp_LHlsvS7o=.a0df0b9d-bc6a-484d-9875-37eba8c068aa@github.com>
Message-ID: <a7aqfDIOAb9uLnGq5BsN3cVPmu794_M_K3ZV6LMuh4w=.60038844-5f14-4c77-8555-f30d422d0673@github.com>

On Tue, 7 Jan 2025 18:08:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> One of my testing nodes caught the OOM kill for the VM carrying the test. The default configuration turns the VM that test runs as the driver into a memory hog. On 48-core / 64G machine, the test configured itself to take 13 workers each allocating 1G. This ballooned the heap size to 13G -- e.g. about 25% of host memory  -- which is well beyond the usual footprint for a single test VM (~2GB). Naturally, this runs into a high chance of being OOM killed under high test parallelism.
> 
> I think the solution is to cut down the heap size we run with, and balance the number of workers a bit more finely. I looked around at sibling tests and 1G seems to be a common heap size for these tests.

This pull request has now been integrated.

Changeset: dff5719e
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dff5719e6f95f9ce50a5d49adf13541e22f7b5b1
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8347126: gc/stress/TestStressG1Uncommit.java gets OOM-killed

Reviewed-by: tschatzl, gli

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

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

From shade at openjdk.org  Thu Jan  9 10:05:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Jan 2025 10:05:40 GMT
Subject: RFR: 8347256: Epsilon: Demote heap size and AlwaysPreTouch
 warnings to info level
In-Reply-To: <L0zRMvlruXRbaBW_a7fq6bC2NEQOeTxQsdDYOjgxM5g=.713ff6cb-cf5c-4379-b1fc-0ba3a59d55c3@github.com>
References: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>
 <L0zRMvlruXRbaBW_a7fq6bC2NEQOeTxQsdDYOjgxM5g=.713ff6cb-cf5c-4379-b1fc-0ba3a59d55c3@github.com>
Message-ID: <4I5h1g5_Mn_qoCX8W8KCrCY6BxgbEPwnwR3MycwVaqw=.fa92dc34-71b7-4d35-9cc7-200c33038a00@github.com>

On Wed, 8 Jan 2025 15:50:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> For Epsilon, we have added `log_warning` messages when heap size and AlwaysPreTouch configuration is not great with [JDK-8232051](https://bugs.openjdk.org/browse/JDK-8232051). Unfortunately, this means we print this warning all the time, even though users might not actually run into problems there, or when users tried to implement these suggestions and still decided to run against them.
>> 
>> I think we want to emit the suggestions in the normal GC log instead, so they are not printed all the time. Additionally, I moved the printing at the end of init logger, so it does not come in the middle of `gc,init` block.
>> 
>> Output before:
>> 
>> 
>> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
>> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
>> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
>> Hello!
>> 
>> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
>> [0.008s][info][gc] Using Epsilon
>> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
>> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
>> Hello!
>> [0.757s][info   ][gc     ] Heap: 1024M reserved, 129M (12.60%) committed, 23906K (2.28%) used
>> 
>> 
>> Output after:
>> 
>> 
>> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
>> Hello!
>> 
>> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
>> [0.009s][info][gc] Using Epsilon
>> [0.009s][info][gc] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
>> [0.009s][info][gc] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
>> Hello!
>> [0.753s][info][gc] Heap: 1024M reserved, 129M (12.60%) committed, 23908K (2.28%) used
>
> lgtm.

Thank you @tschatzl! I think I need another Review to merge this. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22965#issuecomment-2579655476

From tschatzl at openjdk.org  Thu Jan  9 12:28:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 9 Jan 2025 12:28:41 GMT
Subject: RFR: 8347279: Problemlist TestEvilSyncBug.java#generational
In-Reply-To: <3Ytom-NSY6xE6P0PerrVxrCd4lM3LqJ2LYkXSm0NG6c=.3c9b94cb-5c43-498f-b80e-557aa61e2635@github.com>
References: <3Ytom-NSY6xE6P0PerrVxrCd4lM3LqJ2LYkXSm0NG6c=.3c9b94cb-5c43-498f-b80e-557aa61e2635@github.com>
Message-ID: <ngSQ9NBMdxp9DNfYthaloT0RM5R9TkOJ79YeRJ5c-jg=.fa65cbaf-84f6-4ec1-84ac-b6a3ee287eef@github.com>

On Thu, 9 Jan 2025 03:46:29 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test gc/shenandoah/TestEvilSyncBug.java#generational was observed times out on a lot of platforms (various Linux and Windows too) several times recently. Should we Problemlist this test before the failure root cause been fixed.

Lgtm and trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22996#pullrequestreview-2539789222

From simonis at openjdk.org  Thu Jan  9 14:04:42 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 9 Jan 2025 14:04:42 GMT
Subject: RFR: 8343658: Parallel: Implement block_start for Young generation
In-Reply-To: <d32zlxIzcyDMl5TPtsewxAKYlmRlJs6qVgdeg57FMjw=.7874e920-7274-4444-948b-ecb4663f6d2d@github.com>
References: <d32zlxIzcyDMl5TPtsewxAKYlmRlJs6qVgdeg57FMjw=.7874e920-7274-4444-948b-ecb4663f6d2d@github.com>
Message-ID: <XGuzh4xRbIrZJQr7oqrFc9dD4WzVqPAKJuwnh6T4Y04=.4455e75f-c77f-413d-856d-75ab5f209739@github.com>

On Wed, 6 Nov 2024 08:04:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple block_start implementation for Parallel young-gen. Related to https://github.com/openjdk/jdk/pull/21870
> 
> Test: tier1-3

It's hard to create a reproducible test case for a crash in print location because it requires you to load a specific bogus value (which points into the unallocted part of the heap) into a register just before the crash. It's easy though to trigger it manually in the debugger as described in https://github.com/openjdk/jdk/pull/21919#issuecomment-2577275582.

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

PR Comment: https://git.openjdk.org/jdk/pull/21919#issuecomment-2580274187

From wkemper at openjdk.org  Thu Jan  9 17:09:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Jan 2025 17:09:41 GMT
Subject: [jdk24] Integrated: 8346737: GenShen: Generational memory pools should
 not report zero for maximum capacity
In-Reply-To: <npQ6aTvYAGkDIh0KoSyPOxUIFKtz2VCBewDkGlSG55k=.601ac51b-983a-4832-850a-d09dbba72c19@github.com>
References: <npQ6aTvYAGkDIh0KoSyPOxUIFKtz2VCBewDkGlSG55k=.601ac51b-983a-4832-850a-d09dbba72c19@github.com>
Message-ID: <0za45SpKfNjBbXsh5lBROU3kBFsbCZ-Cyh8uPoG7Mto=.9bff78a4-6a0a-4824-8757-0ce15eab06f9@github.com>

On Wed, 8 Jan 2025 23:26:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes many SA tests.

This pull request has now been integrated.

Changeset: ff9b8e46
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ff9b8e4607e28cf2b165f3ff170b17e6b6d8a8a5
Stats:     6 lines in 2 files changed: 0 ins; 6 del; 0 mod

8346737: GenShen: Generational memory pools should not report zero for maximum capacity

Reviewed-by: kdnilsen, ysr
Backport-of: 249f141211c94afcce70d9d536d84e108e07b4e5

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

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

From wkemper at openjdk.org  Thu Jan  9 17:21:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Jan 2025 17:21:38 GMT
Subject: RFR: 8347279: Problemlist TestEvilSyncBug.java#generational
In-Reply-To: <3Ytom-NSY6xE6P0PerrVxrCd4lM3LqJ2LYkXSm0NG6c=.3c9b94cb-5c43-498f-b80e-557aa61e2635@github.com>
References: <3Ytom-NSY6xE6P0PerrVxrCd4lM3LqJ2LYkXSm0NG6c=.3c9b94cb-5c43-498f-b80e-557aa61e2635@github.com>
Message-ID: <82aA2LLwQY71hSKd48xTwMuN0YDFg8uP2hWUISGNJO4=.a79f224b-ad1c-409b-826e-baabf04d9a35@github.com>

On Thu, 9 Jan 2025 03:46:29 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test gc/shenandoah/TestEvilSyncBug.java#generational was observed times out on a lot of platforms (various Linux and Windows too) several times recently. Should we Problemlist this test before the failure root cause been fixed.

Thank you for this.

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22996#pullrequestreview-2540509493

From wkemper at openjdk.org  Thu Jan  9 17:47:26 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Jan 2025 17:47:26 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v2]
In-Reply-To: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
Message-ID: <tU5X1XBsTMwDx5Eit1KX3I9wx60yX_Du4Ios67APG3U=.ca477ab7-ff79-41f9-a982-2f967a3d3343@github.com>

> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
> 
> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
> 
> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.

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 32 additional commits since the last revision:

 - Improve comments
 - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
 - Fix comments
 - Fix comment, revert unnecessary change
 - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
 - Fix phase encoding to handle weak roots
 - WIP: Use Threads::threads_do for propagating gc state (consolidated)
 - WIP: Use Threads::threads_do for propagating gc state
 - Remove unnecessary gc state propagations
 - Encapsulate gc state
 - ... and 22 more: https://git.openjdk.org/jdk/compare/967c77a7...83ac7b49

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22688/files
  - new: https://git.openjdk.org/jdk/pull/22688/files/9aaef708..83ac7b49

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

  Stats: 31726 lines in 2167 files changed: 20848 ins; 5389 del; 5489 mod
  Patch: https://git.openjdk.org/jdk/pull/22688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22688/head:pull/22688

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

From xpeng at openjdk.org  Thu Jan  9 19:10:37 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 9 Jan 2025 19:10:37 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v3]
In-Reply-To: <6kG3_NLd3D4G9fYnrmdKw-s25Fsmu1rLwOV_6eRDrfI=.cd23eb62-96b9-459f-a313-2d4ae7762284@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
 <dM5MCVZSF9knRaGdmymF34oknNNnnG5BZyFHPtEvNIg=.0244a9d4-e242-45ce-b26a-1bad65f5f34a@github.com>
 <c7jTu7X5Lo8EpAlp1rywuDMhok7RnaQalgphByITXy4=.78d476a9-1ec3-49f7-ab79-3b5b01e79ea3@github.com>
 <ir7v8yCpyQhZC2CAz6q7JjQgjnYEHLwCM3oLPQN740w=.9e88f4ed-a264-40d7-85f2-1e80b3683b91@github.com>
 <f2c7EM433O6AJ_mEQm3ZTSgF0BiQpYneeLWBS92kmjg=.2877e277-7a1f-4694-a04b-a6490254f2c1@github.com>
 <6kG3_NLd3D4G9fYnrmdKw-s25Fsmu1rLwOV_6eRDrfI=.cd23eb62-96b9-459f-a313-2d4ae7762284@github.com>
Message-ID: <vmVTOKJHcp-oYGEz-1On6Ay7Jo58BVlr42rVlZkAwoI=.7fc3f256-b35f-4a10-ba33-47f73a749e99@github.com>

On Wed, 8 Jan 2025 20:47:44 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> That sounds like an issue with the verifier then? Once a young cycle is complete, nothing should depend on the state of the bitmaps for young regions (if, for no other reason, evacuation could have moved objects so that the bitmaps no longer represent the addresses of marked objects that were evacuated).
>
> I agree with @earthling-amzn that we should be able to reset young-generation mark bitmap even if this is old_gc_bootstrap and even if old marking is in progress.  We should dive deeper to figure out the crash you observed.  It seems we don't fully understand the root cause.
> 
> I also suggest rewording the comment.  trigged?  (See other comments about increasing generality of this approach.)

I have tested it after removing `if (!_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress())`, and always get crash in stress test like:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/codebuild/output/src48/src/s3/00/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:1270), pid=1578, tid=1595
#  Error: Remembered set violation at init-update-references; clean card should be dirty
Referenced from:
  interior location: 0x00000007f8000008
  inside Java heap
    not in collection set
  region: | 2528|R  |O|BTE    7f8000000,    7f8400000,    7f8400000|TAMS    7f8400000|UWM    7f8400000|U  4096K|T     0B|G  4096K|P     0B|S     0B|L   672B|CP   0
Object:
  0x00000007f5dc8b58 - klass 0x0000078000249400 java.lang.invoke.MethodType
    not allocated after mark start
    not after update watermark
        marked strong
    not marked weak
    not in collection set
  age: 8
  mark: mark(is_unlocked no_hash age=8)
  region: | 2519|R  |Y|BTE    7f5c00000,    7f6000000,    7f6000000|TAMS    7f6000000|UWM    7f6000000|U  4096K|T     0B|G  4096K|P     0B|S     0B|L  4091K|CP   0

It could be something wrong in remembered set scan, resetting young region bitmaps somehow tickles the issue.

I have created another [JBS ticket](https://bugs.openjdk.org/browse/JDK-8347371) to track the issue in remembered set scan, and keep this test for now. I'll update the comments in code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1909312883

From xpeng at openjdk.org  Thu Jan  9 19:28:08 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 9 Jan 2025 19:28:08 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v4]
In-Reply-To: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
Message-ID: <5u5owTlpSq3Y69GNr2LGLerK6uTR0i0_-rYZ1Q6wrnc=.1af37f2c-00ad-4589-a3d9-666a216fb1af@github.com>

> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
> 
> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
> 
> GenShen:
> Before:
> 
> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
> 
> 
> After:
> 
> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
> 
> 
> Shenandoah:
> Before:
> 
> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
> 
> After:
> 
> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
> 
> 
> Additional changes:
> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
> * Clean up FullGC code, remove duplicate code.
> 
> Additional tests:
> - [x] CONF=macosx-aarch64-server-fastdebug make test T...

Xiaolong Peng has updated the pull request incrementally with three additional commits since the last revision:

 - Adding condition "!_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress()" back and address some PR comments
 - Remove entry_reset_after_collect from ShenandoahOldGC
 - Remove condition check !_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress() from op_reset_after_collect

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22778/files
  - new: https://git.openjdk.org/jdk/pull/22778/files/f82fdfaa..04299a76

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

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

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

From xpeng at openjdk.org  Thu Jan  9 19:28:08 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 9 Jan 2025 19:28:08 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v3]
In-Reply-To: <kzuT2ioU_c8Q2R5YlluU8fyQ_sjinu9E-CVhDJlnLm0=.2d999edf-8473-499a-a731-349be7f4006f@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <OfmB9ehsC_CJI5Pv7JfEsyieZndfEPUa7wiDIz3PDpw=.5bfc80b3-11de-4af4-a095-55958b17da3d@github.com>
 <Q0hgluLJUb5jeaz27fELFXYpDkgrFfcY9B6OufCtal8=.87af8e26-7ac8-4484-bf33-d9074af06f42@github.com>
 <kzuT2ioU_c8Q2R5YlluU8fyQ_sjinu9E-CVhDJlnLm0=.2d999edf-8473-499a-a731-349be7f4006f@github.com>
Message-ID: <F8_vbPQtmsbI4vtECfI3XS-OiumFvj9wOvbpggskqOg=.dc6b826c-9362-4683-bd97-326dcc590f8c@github.com>

On Wed, 8 Jan 2025 22:46:12 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 242:
>> 
>>> 240:   // Instead of always reset before collect, some reset can be done after collect to save
>>> 241:   // the time before before the cycle so the cycle can be started as soon as possible.
>>> 242:   entry_reset_after_collect();
>> 
>> For comment, I would say: "Instead of always resetting immediately before the start of a new GC, we can often reset at the end of the previous GC.  This allows us to start the next GC cycle more quickly after a trigger condition is detected, reducing the likelihood that GC will degenerate."
>
> I'll update comments, thanks Kelvin!

Fixed. thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1909330187

From xpeng at openjdk.org  Thu Jan  9 19:40:45 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 9 Jan 2025 19:40:45 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v3]
In-Reply-To: <a0X6VZa2qUKYeHmH9DxX-77dC8QFBveDIvDu-Cp94Zo=.d0315855-4b50-427f-8d65-cb80c0f0f89e@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <OfmB9ehsC_CJI5Pv7JfEsyieZndfEPUa7wiDIz3PDpw=.5bfc80b3-11de-4af4-a095-55958b17da3d@github.com>
 <Q0hgluLJUb5jeaz27fELFXYpDkgrFfcY9B6OufCtal8=.87af8e26-7ac8-4484-bf33-d9074af06f42@github.com>
 <a0X6VZa2qUKYeHmH9DxX-77dC8QFBveDIvDu-Cp94Zo=.d0315855-4b50-427f-8d65-cb80c0f0f89e@github.com>
Message-ID: <uIDmEv9Xxfupf2EtMw5NgK4Sk98CUESZcK4UsXIltpU=.3cf16e2d-8780-45a6-874c-40c0f94fb39c@github.com>

On Wed, 8 Jan 2025 21:38:16 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 592:
>> 
>>> 590:   // If it is old GC bootstrap cycle, always clear bitmap for global gen
>>> 591:   // to ensure bitmap for old gen is clear for old GC cycle after this.
>>> 592:   if (_do_old_gc_bootstrap) {
>> 
>> This may deserve a comment.  It seems we ought to clear the old-gen mark bitmap at the end of coalesce-and-fill.  But that does not allow us to avoid clearing old-gen mark bitmaps at start of bootstrap because when young-gen regions are promoted in place, the mark bitmap is preserved for those regions, and since they are considered old at the end of the GC cycle during which they were promoted, those bitmaps will not be cleared by op_reset_after_collect().  Is there a way to improve this behavior?
>> 
>> For example, in op_reset_after_collect(), maybe we should clear old-gen bitmaps also (at least for recently promoted in place regions) unless old marking is in process and/or mixed evacuations are in progress.
>> 
>> Maybe this can be tackled in a separate PR, but would be good to file JBS ticket now if there is agreement on the approach.
>
> Yes, We can reset bimap of old region when there in place promotion and all old regions after coalesce-and-fill for old gen. 
> 
> Thanks Kelvin, I'll create a JBS ticket for this.

This is ShenandoahConcurrentGC::op_reset(), it is executed when a cycle starts. I have removed line 361 to 371, which traverse all regions and apply reset for old regions when `_do_old_gc_bootstrap` is true, so it used to iterate regions twice when `_do_old_gc_bootstrap` is true. With this change, it only iterate once and reset bitmap for all regions when `_do_old_gc_bootstrap` is true.

Here is the ticket https://bugs.openjdk.org/browse/JDK-8347372 to follow up the possible improvements on old GC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1909344212

From xpeng at openjdk.org  Thu Jan  9 19:53:05 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 9 Jan 2025 19:53:05 GMT
Subject: [jdk24] RFR: 8345423: Shenandoah: Parallelize concurrent cleanup
Message-ID: <RMlGwAiMuvqgVKfkp02_vhqfywMHFmtyxAcBBCzG7uQ=.6ec44015-765f-42fa-bc7d-3e378a502bf6@github.com>

Clean backport, improve performance of concurrent cleanup of Shenandoah and GenShen, remove the use of heap lock from concurrent cleanup.

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

Commit messages:
 - Backport 4da6fd4283a13be1711e7ad948f1d05a0a9148a5

Changes: https://git.openjdk.org/jdk/pull/22991/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22991&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345423
  Stats: 228 lines in 13 files changed: 79 ins; 56 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/22991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22991/head:pull/22991

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

From xpeng at openjdk.org  Thu Jan  9 22:44:45 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 9 Jan 2025 22:44:45 GMT
Subject: [jdk24] Withdrawn: 8345423: Shenandoah: Parallelize concurrent cleanup
In-Reply-To: <RMlGwAiMuvqgVKfkp02_vhqfywMHFmtyxAcBBCzG7uQ=.6ec44015-765f-42fa-bc7d-3e378a502bf6@github.com>
References: <RMlGwAiMuvqgVKfkp02_vhqfywMHFmtyxAcBBCzG7uQ=.6ec44015-765f-42fa-bc7d-3e378a502bf6@github.com>
Message-ID: <a6Q3Tj_pMpOs63NPo-5WwfSP79hH2gb961TaaIYblQU=.0fa47a2f-533e-4e2e-8625-438ffc614c33@github.com>

On Wed, 8 Jan 2025 23:57:36 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Clean backport, improve performance of concurrent cleanup of Shenandoah and GenShen, remove the use of heap lock from concurrent cleanup.

This pull request has been closed without being integrated.

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

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

From phh at openjdk.org  Thu Jan  9 23:26:35 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 9 Jan 2025 23:26:35 GMT
Subject: RFR: 8347256: Epsilon: Demote heap size and AlwaysPreTouch
 warnings to info level
In-Reply-To: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>
References: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>
Message-ID: <nkMCaUZKTn75OS_AOYsbZObd9O5vRHNmXkjuLp5wrPc=.17498e81-0e60-4cb5-bcda-789d7bfa61ea@github.com>

On Wed, 8 Jan 2025 10:58:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For Epsilon, we have added `log_warning` messages when heap size and AlwaysPreTouch configuration is not great with [JDK-8232051](https://bugs.openjdk.org/browse/JDK-8232051). Unfortunately, this means we print this warning all the time, even though users might not actually run into problems there, or when users tried to implement these suggestions and still decided to run against them.
> 
> I think we want to emit the suggestions in the normal GC log instead, so they are not printed all the time. Additionally, I moved the printing at the end of init logger, so it does not come in the middle of `gc,init` block.
> 
> Output before:
> 
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
> [0.008s][info][gc] Using Epsilon
> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> [0.757s][info   ][gc     ] Heap: 1024M reserved, 129M (12.60%) committed, 23906K (2.28%) used
> 
> 
> Output after:
> 
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
> Hello!
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
> [0.009s][info][gc] Using Epsilon
> [0.009s][info][gc] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.009s][info][gc] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> [0.753s][info][gc] Heap: 1024M reserved, 129M (12.60%) committed, 23908K (2.28%) used

Marked as reviewed by phh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22965#pullrequestreview-2541142051

From ysr at openjdk.org  Fri Jan 10 00:42:47 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 10 Jan 2025 00:42:47 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v2]
In-Reply-To: <tU5X1XBsTMwDx5Eit1KX3I9wx60yX_Du4Ios67APG3U=.ca477ab7-ff79-41f9-a982-2f967a3d3343@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <tU5X1XBsTMwDx5Eit1KX3I9wx60yX_Du4Ios67APG3U=.ca477ab7-ff79-41f9-a982-2f967a3d3343@github.com>
Message-ID: <nEqRK4VE1_Zj5m2e-9lzor9PqsEpQ832s6T_2xYcmfE=.fe388f8d-36c6-4dca-ad6b-058563c5aafd@github.com>

On Thu, 9 Jan 2025 17:47:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
>> 
>> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
>> 
>> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.
>
> 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 32 additional commits since the last revision:
> 
>  - Improve comments
>  - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
>  - Fix comments
>  - Fix comment, revert unnecessary change
>  - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
>  - Fix phase encoding to handle weak roots
>  - WIP: Use Threads::threads_do for propagating gc state (consolidated)
>  - WIP: Use Threads::threads_do for propagating gc state
>  - Remove unnecessary gc state propagations
>  - Encapsulate gc state
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/e0773235...83ac7b49

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 368:

> 366:   // This updates the singular, global gc state. This call must happen on a safepoint.
> 367:   // However, in some cases (init update refs, e.g.), the gc state may change concurrently
> 368:   // and will be propagated to all threads by a handshake operation.

I am a little bit confused by the statement starting at "However, ...". Did you mean that the "local copy of the global state" may be changed outside of a safepoint but not the global state itself? 
I notice that `set_gc_state()` still asserts that we are at a safepoint:
https://github.com/openjdk/jdk/blob/83ac7b49d34081beb3ff58f1c159d22faacd077a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2000

Ah, now I see that you use a different API for setting the global gc state outside of a safepoint.

If my understanding is correct, then we should probably rename the APIs such that the one that is expected to be set at a safepoint uses `set_gc_state_at_safepoint()` and the one that doesn't might use `set_gc_state_concurrent()` or something like that. That would be less confusing.

It also brings up the issue of what specific state predicates it's safe to test when. E.g. whether `is_gc_state()` can be safely tested any time during a safepoint or concurrently. I think it is safe, but explicitly stating this might be useful, not least because we seem to have one state change API that still asserts that we should be at a safepoint.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1909623411

From syan at openjdk.org  Fri Jan 10 01:41:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 10 Jan 2025 01:41:49 GMT
Subject: RFR: 8347279: Problemlist TestEvilSyncBug.java#generational
In-Reply-To: <3Ytom-NSY6xE6P0PerrVxrCd4lM3LqJ2LYkXSm0NG6c=.3c9b94cb-5c43-498f-b80e-557aa61e2635@github.com>
References: <3Ytom-NSY6xE6P0PerrVxrCd4lM3LqJ2LYkXSm0NG6c=.3c9b94cb-5c43-498f-b80e-557aa61e2635@github.com>
Message-ID: <lM1ohu2uuL8DX6lMUA8hOkJif8nNMSwVgWnZKxUfehA=.c304a7d4-f080-4852-9c04-03fac456bc49@github.com>

On Thu, 9 Jan 2025 03:46:29 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test gc/shenandoah/TestEvilSyncBug.java#generational was observed times out on a lot of platforms (various Linux and Windows too) several times recently. Should we Problemlist this test before the failure root cause been fixed.

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22996#issuecomment-2581565626

From syan at openjdk.org  Fri Jan 10 01:41:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 10 Jan 2025 01:41:49 GMT
Subject: Integrated: 8347279: Problemlist TestEvilSyncBug.java#generational
In-Reply-To: <3Ytom-NSY6xE6P0PerrVxrCd4lM3LqJ2LYkXSm0NG6c=.3c9b94cb-5c43-498f-b80e-557aa61e2635@github.com>
References: <3Ytom-NSY6xE6P0PerrVxrCd4lM3LqJ2LYkXSm0NG6c=.3c9b94cb-5c43-498f-b80e-557aa61e2635@github.com>
Message-ID: <vHjQVse57bIsr7BZKjQBKGuCG3XWdmMQ6JxblGwk1N8=.430d1e28-5d33-44af-b238-3541a100292d@github.com>

On Thu, 9 Jan 2025 03:46:29 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test gc/shenandoah/TestEvilSyncBug.java#generational was observed times out on a lot of platforms (various Linux and Windows too) several times recently. Should we Problemlist this test before the failure root cause been fixed.

This pull request has now been integrated.

Changeset: f6492aa6
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6492aa63486393593ea8761cef5362ef46abf13
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8347279: Problemlist TestEvilSyncBug.java#generational

Reviewed-by: tschatzl, wkemper

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

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

From shade at openjdk.org  Fri Jan 10 08:45:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 08:45:45 GMT
Subject: RFR: 8347256: Epsilon: Demote heap size and AlwaysPreTouch
 warnings to info level
In-Reply-To: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>
References: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>
Message-ID: <tNEZ8aXK8-s6lgv5Cw3owrUTPtgxvk8XxsKkE6NmvtM=.53264dd8-2f1d-40f1-9e90-222aa5e6204f@github.com>

On Wed, 8 Jan 2025 10:58:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For Epsilon, we have added `log_warning` messages when heap size and AlwaysPreTouch configuration is not great with [JDK-8232051](https://bugs.openjdk.org/browse/JDK-8232051). Unfortunately, this means we print this warning all the time, even though users might not actually run into problems there, or when users tried to implement these suggestions and still decided to run against them.
> 
> I think we want to emit the suggestions in the normal GC log instead, so they are not printed all the time. Additionally, I moved the printing at the end of init logger, so it does not come in the middle of `gc,init` block.
> 
> Output before:
> 
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
> [0.008s][info][gc] Using Epsilon
> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> [0.757s][info   ][gc     ] Heap: 1024M reserved, 129M (12.60%) committed, 23906K (2.28%) used
> 
> 
> Output after:
> 
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
> Hello!
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
> [0.009s][info][gc] Using Epsilon
> [0.009s][info][gc] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.009s][info][gc] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> [0.753s][info][gc] Heap: 1024M reserved, 129M (12.60%) committed, 23908K (2.28%) used

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22965#issuecomment-2582068172

From shade at openjdk.org  Fri Jan 10 08:45:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 08:45:45 GMT
Subject: Integrated: 8347256: Epsilon: Demote heap size and AlwaysPreTouch
 warnings to info level
In-Reply-To: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>
References: <GpZH3Z8a2HjS5v0txS2ug9r8HM2f_JwPpVpFMTxdrF8=.7429c6d2-e65a-4e1d-8a46-cf5a08c1684d@github.com>
Message-ID: <N9O0yc0k4RS90Qh1Wyx_wn1rdqbjGoYSfwY2B-HDzhM=.521acff7-a1c5-4d74-98c0-3f4305880963@github.com>

On Wed, 8 Jan 2025 10:58:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For Epsilon, we have added `log_warning` messages when heap size and AlwaysPreTouch configuration is not great with [JDK-8232051](https://bugs.openjdk.org/browse/JDK-8232051). Unfortunately, this means we print this warning all the time, even though users might not actually run into problems there, or when users tried to implement these suggestions and still decided to run against them.
> 
> I think we want to emit the suggestions in the normal GC log instead, so they are not printed all the time. Additionally, I moved the printing at the end of init logger, so it does not come in the middle of `gc,init` block.
> 
> Output before:
> 
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
> [0.008s][info][gc] Using Epsilon
> [0.008s][warning][gc,init] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.008s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> [0.757s][info   ][gc     ] Heap: 1024M reserved, 129M (12.60%) committed, 23906K (2.28%) used
> 
> 
> Output after:
> 
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Hello.java 
> Hello!
> 
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xlog:gc Hello.java 
> [0.009s][info][gc] Using Epsilon
> [0.009s][info][gc] Consider setting -Xms equal to -Xmx to avoid resizing hiccups
> [0.009s][info][gc] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
> Hello!
> [0.753s][info][gc] Heap: 1024M reserved, 129M (12.60%) committed, 23908K (2.28%) used

This pull request has now been integrated.

Changeset: 1a0fe497
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a0fe49732187db9e8776f80feefab4373114f75
Stats:     24 lines in 1 file changed: 12 ins; 12 del; 0 mod

8347256: Epsilon: Demote heap size and AlwaysPreTouch warnings to info level

Reviewed-by: tschatzl, phh

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

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

From kbarrett at openjdk.org  Fri Jan 10 11:25:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Jan 2025 11:25:55 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds
Message-ID: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>

Please review this change to PSStripeShadowCardTable to avoid several examples
of UB in it's internal calculations.  We avoid the UB by switching to the
integer domain (using uintptr_t) for all of the internal calculations, with
casts between pointers and uintptr_t as needed at the boundaries.

This applies not just to the various pointer adjustments, but also to pointer
comparisons. In particular, the prior range check assertions using pointer
comparisons could have been partially or even completely "optimized" away
based on the no-UB assumption.

Testing: mach5 tier1-5
local (linux-x64) tier1 with -XX:+UseParallelGC

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

Commit messages:
 - avoid UB

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

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

From szaldana at redhat.com  Fri Jan 10 14:15:34 2025
From: szaldana at redhat.com (Sonia Zaldana Calles)
Date: Fri, 10 Jan 2025 09:15:34 -0500
Subject: GCOverheadLimit support for G1
Message-ID: <CADo2k6tfD4T-WP9RUdZPFGjPh7rbf=_hVQpdZCGCsTuQ5DwtKg@mail.gmail.com>

Hi folks,

Upon migration from ParallelGC to G1, we have a report that G1 is
showcasing a slow death when too much time is spent in garbage collection,
in contrast to ParallelGC, which would trigger an ?OutOfMemoryError: GC
Overhead limit exceeded?.

Note the single class reproducer below [0]. Running with java ... -Xlog:gc
-Xmx4G, we can observe long pauses (~3-4 seconds on my machine), the VM
attempts ~20 Full GC cycles where the last full GCs take a lot longer than
the pause time goal of 200ms. Ideally, we would like the JVM to stop trying
at some point early (similarly to ParallelGC) and we have not found a way
to accomplish that.

We found this is likely because UseGCOverheadLimit is only supported (and
enabled by default) for the ParallelGC. We came across JDK-8212084 and we
were wondering if there was a particular reason this didn?t move forward?
[1] Is there anything we can do to help?

[0]

import java.util.LinkedList;

public class GCOverheadReproducer {

  private static final LinkedList fixedData = new LinkedList();

  private static final int FIXED_DATA_ITEM_SIZE = 32;

  private static final int TEMPORARY_DATA_ITEM_SIZE = FIXED_DATA_ITEM_SIZE
/ 2 - 1;

  public static void main(String[] args) throws InterruptedException {

    System.out.println("Consuming all memory");

    while (true) {

      try {

        fixedData.add(new byte[FIXED_DATA_ITEM_SIZE]);

      } catch (OutOfMemoryError oome) {

        System.out.println(oome);

        System.out.printf("OOME triggered. Releasing %s bytes of
memory.\n", FIXED_DATA_ITEM_SIZE);

        fixedData.removeLast();

        break;

      }

    }

    System.out.println("Running allocate-release loop");

    while (true) {

      Object temporaryData = new byte[TEMPORARY_DATA_ITEM_SIZE];

    }

  }

}

[1] https://bugs.openjdk.org/browse/JDK-8212084

Thanks,

Sonia

-- 
Sonia Zalda?a Calles
Software Engineer, OpenJDK
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250110/4b42602d/attachment-0001.htm>

From xpeng at openjdk.org  Fri Jan 10 17:08:10 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 10 Jan 2025 17:08:10 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v5]
In-Reply-To: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
Message-ID: <JE6-b-HXDHgxJevBGFOtnV3wwis_70yVRqCca-Q4edc=.ed49489d-c4c6-481e-b46a-9180cc178b0a@github.com>

> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
> 
> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
> 
> GenShen:
> Before:
> 
> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
> 
> 
> After:
> 
> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
> 
> 
> Shenandoah:
> Before:
> 
> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
> 
> After:
> 
> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
> 
> 
> Additional changes:
> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
> * Clean up FullGC code, remove duplicate code.
> 
> Additional tests:
> - [x] CONF=macosx-aarch64-server-fastdebug make test T...

Xiaolong Peng 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 21 additional commits since the last revision:

 - Merge branch 'openjdk:master' into reset-bitmap
 - Adding condition "!_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress()" back and address some PR comments
 - Remove entry_reset_after_collect from ShenandoahOldGC
 - Remove condition check !_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress() from op_reset_after_collect
 - Merge branch 'openjdk:master' into reset-bitmap
 - Address review comments
 - Merge branch 'openjdk:master' into reset-bitmap
 - Remove ShenandoahResetUpdateRegionStateClosure
 - Always set_mark_incomplete when reset mark bitmap
 - Fix
 - ... and 11 more: https://git.openjdk.org/jdk/compare/15c49f96...5a181473

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22778/files
  - new: https://git.openjdk.org/jdk/pull/22778/files/04299a76..5a181473

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

  Stats: 20964 lines in 584 files changed: 5664 ins; 12721 del; 2579 mod
  Patch: https://git.openjdk.org/jdk/pull/22778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22778/head:pull/22778

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

From wkemper at openjdk.org  Fri Jan 10 19:35:46 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 10 Jan 2025 19:35:46 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v2]
In-Reply-To: <nEqRK4VE1_Zj5m2e-9lzor9PqsEpQ832s6T_2xYcmfE=.fe388f8d-36c6-4dca-ad6b-058563c5aafd@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <tU5X1XBsTMwDx5Eit1KX3I9wx60yX_Du4Ios67APG3U=.ca477ab7-ff79-41f9-a982-2f967a3d3343@github.com>
 <nEqRK4VE1_Zj5m2e-9lzor9PqsEpQ832s6T_2xYcmfE=.fe388f8d-36c6-4dca-ad6b-058563c5aafd@github.com>
Message-ID: <zWg0PADzWe6h3iOHYMxy4WrTvUiYmTiuBguXaF1XzxE=.81ab1366-5bd2-43c3-b6e7-fbcf0f1b3f64@github.com>

On Fri, 10 Jan 2025 00:40:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> 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 32 additional commits since the last revision:
>> 
>>  - Improve comments
>>  - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
>>  - Fix comments
>>  - Fix comment, revert unnecessary change
>>  - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
>>  - Fix phase encoding to handle weak roots
>>  - WIP: Use Threads::threads_do for propagating gc state (consolidated)
>>  - WIP: Use Threads::threads_do for propagating gc state
>>  - Remove unnecessary gc state propagations
>>  - Encapsulate gc state
>>  - ... and 22 more: https://git.openjdk.org/jdk/compare/34b4faa5...83ac7b49
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 368:
> 
>> 366:   // This updates the singular, global gc state. This call must happen on a safepoint.
>> 367:   // However, in some cases (init update refs, e.g.), the gc state may change concurrently
>> 368:   // and will be propagated to all threads by a handshake operation.
> 
> I am a little bit confused by the statement starting at "However, ...". Did you mean that the "local copy of the global state" may be changed outside of a safepoint but not the global state itself? 
> I notice that `set_gc_state()` still asserts that we are at a safepoint:
> https://github.com/openjdk/jdk/blob/83ac7b49d34081beb3ff58f1c159d22faacd077a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2000
> 
> Ah, now I see that you use a different API for setting the global gc state outside of a safepoint.
> 
> If my understanding is correct, then we should probably rename the APIs such that the one that is expected to be set at a safepoint uses `set_gc_state_at_safepoint()` and the one that doesn't might use `set_gc_state_concurrent()` or something like that. That would be less confusing.
> 
> It also brings up the issue of what specific state predicates it's safe to test when. E.g. whether `is_gc_state()` can be safely tested any time during a safepoint or concurrently. I think it is safe, but explicitly stating this might be useful, not least because we seem to have one state change API that still asserts that we should be at a safepoint.

It is always safe to call `is_gc_state` because it uses the most recently changed value. That is, if the `_gc_state` changes on a safepoint, `is_gc_state` will use the value set during the safepoint. Otherwise, it uses the value which was either changed concurrently through the thread local handshake (init-update-refs) or the value which was propagated to all threads at the end of the safepoint.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1911094315

From wkemper at openjdk.org  Fri Jan 10 19:49:17 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 10 Jan 2025 19:49:17 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
Message-ID: <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>

> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
> 
> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
> 
> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments and method names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22688/files
  - new: https://git.openjdk.org/jdk/pull/22688/files/83ac7b49..89c20a14

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

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

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

From kirk at kodewerk.com  Fri Jan 10 20:12:29 2025
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 10 Jan 2025 21:12:29 +0100
Subject: [Discussion] Serial GC: Expand young generation size
In-Reply-To: <SA3PR10MB7022AB3FB889B4ABF2400E85D3122@SA3PR10MB7022.namprd10.prod.outlook.com>
References: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>
 <SA3PR10MB7022AB3FB889B4ABF2400E85D3122@SA3PR10MB7022.namprd10.prod.outlook.com>
Message-ID: <2DB4422C-73F3-4E27-B41B-6028A6BFF51E@kodewerk.com>

Hi Albert,

We are working on adding automated heap sizing (AHS) to the serial collector. One of the issues that we?re looking at is how to expand (or contract) heap as needed. One of the challenges in expanding young gen is the location of data in the heap after a full collection. One of the experiments that we?re currently working on is a rearrangement of the heap so that young can be expanded after a full collection without the need to copy all of the surviving data to accommodate an enlargement of young.

Kind regards,
Kirk

> On Jan 8, 2025, at 11:27?AM, Albert Yang <albert.m.yang at oracle.com> wrote:
> 
> Re https://bugs.openjdk.org/browse/JDK-8333386, I think your suggestion, "add the option `-XX:NewSize=65m`", is the way to go.
> 
> As for adding young-gen expansion support to Serial, it probably should have its own enhancement ticket.
> 
> I am currently working on placing from/to spaces before eden inside young-gen as part of Parallel heap-auto-sizing. I believe Serial can use the same layout (from/to/eden, instead of eden/from/to) to facilitate eden/young-gen expansion. My 2c.
> 
> /Albert
> 
> ________________________________________
> From: hotspot-gc-dev <hotspot-gc-dev-retn at openjdk.org> on behalf of Guoxiong Li <lgxbslgx at gmail.com>
> Sent: Wednesday, January 8, 2025 09:30
> To: hotspot-gc-dev at openjdk.org
> Subject: [Discussion] Serial GC: Expand young generation size
> 
> Hi all,
> 
> Currently, the young generation in SerialGC can't be expanded now
> and is always the initial young generation size. It is not a very big problem generally.
> But in some situations, like JDK-8333386 [1], it will crash the VM (unnecessary OutOfMemoryError).
> 
> So I want to implement the feature to expand the young generation size
> (absolutely, not exceeding the max young generation size).
> What do you think about it? Any ideas will be appreciated.
> 
> Best Regards,
> -- Guoxiong
> 
> Related links:
> [1] https://bugs.openjdk.org/browse/JDK-8333386
> [2] https://bugs.openjdk.org/browse/JDK-8335925
> 


From ysr at openjdk.org  Sat Jan 11 02:04:49 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 11 Jan 2025 02:04:49 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
Message-ID: <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>

On Fri, 10 Jan 2025 19:49:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
>> 
>> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
>> 
>> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments and method names

Left a few more comments, and will make one more final readthrough and approve. Thanks for your continued patience with my slow review!

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 196:

> 194: 
> 195:     // Evacuation is complete, retire gc labs
> 196:     heap->concurrent_prepare_for_update_refs();

For consistency with other related method naming, can we use "updaterefs" instead of "update_refs" (makes IDE searches easier to locate related methods).

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1245:

> 1243:   void do_thread(Thread* thread) override {
> 1244:     _propagator.do_thread(thread);
> 1245:     if (ShenandoahThreadLocalData::gclab(thread) != nullptr) {

Which thread may have this be null? (I am looking at the ShenandoahRetireGCLabClosure which insists that this should be non-null.)

I assume we have some threads here that have a gc state that must be updated but which don't have a gc lab.

I am wondering if the check for an initialized gclab and in the generational case the plab can be pushed down into the closure rather than being exposed here. At that place, we would want to document (or as needed assert) why some threads targeted by the closure may have null gclab or plab.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1267:

> 1265: 
> 1266:   // This will propagate the gc state and retire gclabs and plabs for threads that require it.
> 1267:   ShenandoahPrepareForUpdateRefs prepare_for_update_refs(_gc_state.raw_value());

In looking at this I see that we do not set `_gc_state_changed` here because we don't want individual threads to observe the global state, but only their local state (when it's propagated below). It would be good to emphasise this in the documetation of `_gc_state_changed` use protocol.

Indeed, as I had suggested before, I think this might be better encapsulated with a `set_gc_state_concurrent()` that is analogous to `set_gc_state_at_safepoint()` that takes the appropriate state value as an argument, and uses the appropriate `_gc_state_changed` protocol.

IIUC, this will be re-used when other safepoints are eliminated in the future.

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

PR Review: https://git.openjdk.org/jdk/pull/22688#pullrequestreview-2544388098
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1911793884
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1911797849
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1911803283

From thomas.schatzl at oracle.com  Mon Jan 13 09:24:50 2025
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 13 Jan 2025 10:24:50 +0100
Subject: GCOverheadLimit support for G1
In-Reply-To: <CADo2k6tfD4T-WP9RUdZPFGjPh7rbf=_hVQpdZCGCsTuQ5DwtKg@mail.gmail.com>
References: <CADo2k6tfD4T-WP9RUdZPFGjPh7rbf=_hVQpdZCGCsTuQ5DwtKg@mail.gmail.com>
Message-ID: <ad5a5bcf-3c5e-486c-b4e0-36ee68b6538f@oracle.com>

Hi Sonia,

On 10.01.25 15:15, Sonia Zaldana Calles wrote:
> Hi folks,
> 
> 
> Upon migration from ParallelGC to G1, we have a report that G1 is 
> showcasing a slow death when too much time is spent in garbage 
> collection, in contrast to ParallelGC, which would trigger an 
> ?OutOfMemoryError: GC Overhead limit exceeded?.
> 
> 
> Note the single class reproducer below [0]. Running with java ... - 
> Xlog:gc -Xmx4G, we can observe long pauses (~3-4 seconds on my machine), 
> the VM attempts ~20 Full GC cycles where the last full GCs take a lot 
> longer than the pause time goal of 200ms. Ideally, we would like the JVM 
> to stop trying at some point early (similarly to ParallelGC) and we have 
> not found a way to accomplish that.
> 
> 
> We found this is likely because UseGCOverheadLimit is only supported 
> (and enabled by default) for the ParallelGC. We came across JDK-8212084 
> and we were wondering if there was a particular reason this didn?t move 
> forward? [1] Is there anything we can do to help?
> 
> 

   as most of the time, I do not think there is a particular reason this 
work has not been completed. Just as the comments in that CR indicate, 
that the original problem went away for them and interest has been lost.

Hth,
   Thomas

From thomas.schatzl at oracle.com  Mon Jan 13 09:28:47 2025
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 13 Jan 2025 10:28:47 +0100
Subject: GCOverheadLimit support for G1
In-Reply-To: <ad5a5bcf-3c5e-486c-b4e0-36ee68b6538f@oracle.com>
References: <CADo2k6tfD4T-WP9RUdZPFGjPh7rbf=_hVQpdZCGCsTuQ5DwtKg@mail.gmail.com>
 <ad5a5bcf-3c5e-486c-b4e0-36ee68b6538f@oracle.com>
Message-ID: <c8c48a88-66af-4d95-af57-5927902035b9@oracle.com>

Hi again,

On 13.01.25 10:24, Thomas Schatzl wrote:
> Hi Sonia,
> 
> On 10.01.25 15:15, Sonia Zaldana Calles wrote:
>> Hi folks,
>>
>>
>> Upon migration from ParallelGC to G1, we have a report that G1 is 
>> showcasing a slow death when too much time is spent in garbage 
>> collection, in contrast to ParallelGC, which would trigger an 
>> ?OutOfMemoryError: GC Overhead limit exceeded?.
>>
>>
>> Note the single class reproducer below [0]. Running with java ... - 
>> Xlog:gc -Xmx4G, we can observe long pauses (~3-4 seconds on my 
>> machine), the VM attempts ~20 Full GC cycles where the last full GCs 
>> take a lot longer than the pause time goal of 200ms. Ideally, we would 
>> like the JVM to stop trying at some point early (similarly to 
>> ParallelGC) and we have not found a way to accomplish that.
>>
>>
>> We found this is likely because UseGCOverheadLimit is only supported 
>> (and enabled by default) for the ParallelGC. We came across 
>> JDK-8212084 and we were wondering if there was a particular reason 
>> this didn?t move forward? [1] Is there anything we can do to help?
>>
>>
> 
>  ? as most of the time, I do not think there is a particular reason this 
> work has not been completed. Just as the comments in that CR indicate, 
> that the original problem went away for them and interest has been lost.
> 
Drop the last sentence - having re-read the discussion at 
https://mail.openjdk.org/pipermail/hotspot-gc-dev/2018-October/023525.html, 
I do not think there is a particular reason why it has not been 
implemented apart from losing interest.

Thomas

From rcastanedalo at openjdk.org  Mon Jan 13 09:33:59 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 13 Jan 2025 09:33:59 GMT
Subject: RFR: 8345067: C2: enable implicit null checks for ZGC reads
In-Reply-To: <zBw9632n3CB_GBYsZfrSyXt0ZFwpR_MH32ScHxdSP1I=.2e4195d5-611f-440b-b8ff-226a4622e7a8@github.com>
References: <zBw9632n3CB_GBYsZfrSyXt0ZFwpR_MH32ScHxdSP1I=.2e4195d5-611f-440b-b8ff-226a4622e7a8@github.com>
Message-ID: <FGJhrfuwYTlML9g91jD_j3bvk_dz78ExVgVg4SGTvCY=.f1823351-fe0b-48c3-8be7-fcecc898018a@github.com>

On Wed, 11 Dec 2024 09:59:44 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Currently, C2 cannot exploit late-expanded GC memory accesses as implicit null checks because of their use of temporary operands, which prevents `PhaseCFG::implicit_null_check` from [hoisting the memory accesses to the test basic block](https://github.com/openjdk/jdk/blob/f88c1c6ff86b8f29a71647e46136b6432bb67619/src/hotspot/share/opto/lcm.cpp#L319-L335).
> 
> This changeset extends the scope of the implicit null check optimization so that it can exploit ZGC object loads. It introduces a platform-dependent predicate (`MachNode::has_initial_implicit_null_check_candidate`) to mark late-expanded instructions that emit a suitable memory access as a first instruction as candidates, and extends the optimization to recognize and hoist candidate memory accesses that use temporary operands:
> 
> ![example](https://github.com/user-attachments/assets/b5f9bbc8-d75d-4cf3-841e-73db3dbae753)
> 
> Exploiting ZGC loads increases the effectiveness of the implicit null check optimization (measured in percent of explicit null checks turned into implicit ones at compile time) by around 10% in the DaCapo chopin benchmarks:
> 
> ![C2-inc-hit-rate-jdk-25+1-vs-jdk-25+1-with-8345067](https://github.com/user-attachments/assets/8d114058-c6b2-4254-a374-0d0b220af718)
> 
> The larger number of implicit null checks results in slight performance improvements (in the 1-2% range) in a few DaCapo and SPECjvm2008 benchmarks and an overall slight improvement across Renaissance benchmarks.
> 
> A further extension of the optimization to arbitrary memory access instructions (including e.g. G1 object stores, which emit multiple memory accesses at arbitrary address offsets) will be investigated separately as part of [JDK-8344627](https://bugs.openjdk.org/browse/JDK-8344627).
> 
> #### Testing
> - tier1-5, compiler stress test (linux-x64, macosx-x64, windows-x64, linux-aarch64, macosx-aarch64; release and debug mode).

Putting this PR on hold until the related RFE [JDK-8341611](https://bugs.openjdk.org/browse/JDK-8341611) (with PR https://github.com/openjdk/jdk/pull/22862 under review) is resolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/22678#issuecomment-2586601599

From tschatzl at openjdk.org  Mon Jan 13 09:35:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 Jan 2025 09:35:57 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds
In-Reply-To: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
Message-ID: <g4QaqAL_sQBWeS6tmwKzCDYjo2V5CTpT1eXMNE6v3XQ=.4d163ef8-de7d-4894-97fc-99731c07291a@github.com>

On Fri, 10 Jan 2025 11:21:31 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to PSStripeShadowCardTable to avoid several examples
> of UB in it's internal calculations.  We avoid the UB by switching to the
> integer domain (using uintptr_t) for all of the internal calculations, with
> casts between pointers and uintptr_t as needed at the boundaries.
> 
> This applies not just to the various pointer adjustments, but also to pointer
> comparisons. In particular, the prior range check assertions using pointer
> comparisons could have been partially or even completely "optimized" away
> based on the no-UB assumption.
> 
> Testing: mach5 tier1-5
> local (linux-x64) tier1 with -XX:+UseParallelGC

src/hotspot/share/gc/parallel/psCardTable.cpp line 129:

> 127:   // Avoid UB pointer operations by using integers internally.
> 128: 
> 129:   static_assert(sizeof(intptr_t) == sizeof(CardValue*), "simplifying assumption");

Why check `sizeof(intptr_t)` instead of `uintptr_t` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23032#discussion_r1912898906

From tschatzl at openjdk.org  Mon Jan 13 10:22:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 Jan 2025 10:22:35 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds
In-Reply-To: <g4QaqAL_sQBWeS6tmwKzCDYjo2V5CTpT1eXMNE6v3XQ=.4d163ef8-de7d-4894-97fc-99731c07291a@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
 <g4QaqAL_sQBWeS6tmwKzCDYjo2V5CTpT1eXMNE6v3XQ=.4d163ef8-de7d-4894-97fc-99731c07291a@github.com>
Message-ID: <N544h9Tt1GNDysd9eLkaWDS7BxU6WIRiL5hKYdRletg=.d274bafb-4a60-45c3-9160-f2f9442ef430@github.com>

On Mon, 13 Jan 2025 09:33:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this change to PSStripeShadowCardTable to avoid several examples
>> of UB in it's internal calculations.  We avoid the UB by switching to the
>> integer domain (using uintptr_t) for all of the internal calculations, with
>> casts between pointers and uintptr_t as needed at the boundaries.
>> 
>> This applies not just to the various pointer adjustments, but also to pointer
>> comparisons. In particular, the prior range check assertions using pointer
>> comparisons could have been partially or even completely "optimized" away
>> based on the no-UB assumption.
>> 
>> Testing: mach5 tier1-5
>> local (linux-x64) tier1 with -XX:+UseParallelGC
>
> src/hotspot/share/gc/parallel/psCardTable.cpp line 129:
> 
>> 127:   // Avoid UB pointer operations by using integers internally.
>> 128: 
>> 129:   static_assert(sizeof(intptr_t) == sizeof(CardValue*), "simplifying assumption");
> 
> Why check `sizeof(intptr_t)` instead of `uintptr_t` here?

I mean, the change uses `uintptr_t` throughput, and probably the size of `intptr_t` and `uintptr_t` must be(?) the same, but why not check the actually used type?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23032#discussion_r1912960879

From albert.m.yang at oracle.com  Mon Jan 13 10:27:13 2025
From: albert.m.yang at oracle.com (Albert Yang)
Date: Mon, 13 Jan 2025 10:27:13 +0000
Subject: [External] : Re: [Discussion] Serial GC: Expand young generation
 size
In-Reply-To: <2DB4422C-73F3-4E27-B41B-6028A6BFF51E@kodewerk.com>
References: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>
 <SA3PR10MB7022AB3FB889B4ABF2400E85D3122@SA3PR10MB7022.namprd10.prod.outlook.com>
 <2DB4422C-73F3-4E27-B41B-6028A6BFF51E@kodewerk.com>
Message-ID: <SA3PR10MB7022D5CA0D9053DE9C224AF1D31F2@SA3PR10MB7022.namprd10.prod.outlook.com>

Hi Kirk,

> a rearrangement of the heap so that young can be expanded after a full collection without the need to copy all of the surviving data to accommodate an enlargement of young

Can you elaborate on how you rearranged it? My previous suggestion (from/to before eden) is also a type of rearrangement. I'm curious about how the two compare.

/Albert

________________________________________
From: Kirk Pepperdine <kirk at kodewerk.com>
Sent: Friday, January 10, 2025 21:12
To: Albert Yang
Cc: Guoxiong Li; hotspot-gc-dev at openjdk.org
Subject: [External] : Re: [Discussion] Serial GC: Expand young generation size

Hi Albert,

We are working on adding automated heap sizing (AHS) to the serial collector. One of the issues that we?re looking at is how to expand (or contract) heap as needed. One of the challenges in expanding young gen is the location of data in the heap after a full collection. One of the experiments that we?re currently working on is a rearrangement of the heap so that young can be expanded after a full collection without the need to copy all of the surviving data to accommodate an enlargement of young.

Kind regards,
Kirk

> On Jan 8, 2025, at 11:27?AM, Albert Yang <albert.m.yang at oracle.com> wrote:
>
> Re https://bugs.openjdk.org/browse/JDK-8333386, I think your suggestion, "add the option `-XX:NewSize=65m`", is the way to go.
>
> As for adding young-gen expansion support to Serial, it probably should have its own enhancement ticket.
>
> I am currently working on placing from/to spaces before eden inside young-gen as part of Parallel heap-auto-sizing. I believe Serial can use the same layout (from/to/eden, instead of eden/from/to) to facilitate eden/young-gen expansion. My 2c.
>
> /Albert
>
> ________________________________________
> From: hotspot-gc-dev <hotspot-gc-dev-retn at openjdk.org> on behalf of Guoxiong Li <lgxbslgx at gmail.com>
> Sent: Wednesday, January 8, 2025 09:30
> To: hotspot-gc-dev at openjdk.org
> Subject: [Discussion] Serial GC: Expand young generation size
>
> Hi all,
>
> Currently, the young generation in SerialGC can't be expanded now
> and is always the initial young generation size. It is not a very big problem generally.
> But in some situations, like JDK-8333386 [1], it will crash the VM (unnecessary OutOfMemoryError).
>
> So I want to implement the feature to expand the young generation size
> (absolutely, not exceeding the max young generation size).
> What do you think about it? Any ideas will be appreciated.
>
> Best Regards,
> -- Guoxiong
>
> Related links:
> [1] https://bugs.openjdk.org/browse/JDK-8333386
> [2] https://bugs.openjdk.org/browse/JDK-8335925
>


From kbarrett at openjdk.org  Mon Jan 13 10:42:33 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 Jan 2025 10:42:33 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds [v2]
In-Reply-To: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
Message-ID: <H8HZ9Vel9JOJmL1YpyfXX2keqcyGByc07MXnsN0Nnig=.d1928ea1-ee33-4743-9370-014731f357a5@github.com>

> Please review this change to PSStripeShadowCardTable to avoid several examples
> of UB in it's internal calculations.  We avoid the UB by switching to the
> integer domain (using uintptr_t) for all of the internal calculations, with
> casts between pointers and uintptr_t as needed at the boundaries.
> 
> This applies not just to the various pointer adjustments, but also to pointer
> comparisons. In particular, the prior range check assertions using pointer
> comparisons could have been partially or even completely "optimized" away
> based on the no-UB assumption.
> 
> Testing: mach5 tier1-5
> local (linux-x64) tier1 with -XX:+UseParallelGC

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  typo: intptr_t => uintptr_t

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23032/files
  - new: https://git.openjdk.org/jdk/pull/23032/files/374add7f..58c704f7

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

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

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

From kbarrett at openjdk.org  Mon Jan 13 10:42:34 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 Jan 2025 10:42:34 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds [v2]
In-Reply-To: <N544h9Tt1GNDysd9eLkaWDS7BxU6WIRiL5hKYdRletg=.d274bafb-4a60-45c3-9160-f2f9442ef430@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
 <g4QaqAL_sQBWeS6tmwKzCDYjo2V5CTpT1eXMNE6v3XQ=.4d163ef8-de7d-4894-97fc-99731c07291a@github.com>
 <N544h9Tt1GNDysd9eLkaWDS7BxU6WIRiL5hKYdRletg=.d274bafb-4a60-45c3-9160-f2f9442ef430@github.com>
Message-ID: <UZsCgyJ8JShpmd6bbPA5XZ7G9QPD53cH3aB5pO17JUQ=.d064f7ed-4337-4cec-8f2b-3edbccadd6dc@github.com>

On Mon, 13 Jan 2025 10:19:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psCardTable.cpp line 129:
>> 
>>> 127:   // Avoid UB pointer operations by using integers internally.
>>> 128: 
>>> 129:   static_assert(sizeof(intptr_t) == sizeof(CardValue*), "simplifying assumption");
>> 
>> Why check `sizeof(intptr_t)` instead of `uintptr_t` here?
>
> I mean, the change uses `uintptr_t` throughput, and probably the size of `intptr_t` and `uintptr_t` must be(?) the same, but why not check the actually used type?

typo - fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23032#discussion_r1912984142

From tschatzl at openjdk.org  Mon Jan 13 11:29:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 Jan 2025 11:29:41 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds [v2]
In-Reply-To: <H8HZ9Vel9JOJmL1YpyfXX2keqcyGByc07MXnsN0Nnig=.d1928ea1-ee33-4743-9370-014731f357a5@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
 <H8HZ9Vel9JOJmL1YpyfXX2keqcyGByc07MXnsN0Nnig=.d1928ea1-ee33-4743-9370-014731f357a5@github.com>
Message-ID: <7sweSVqwZcmnqFepnd4Cnl9nJCbuIfreU-mZt3n0a6I=.695c61d4-b2e3-4bc0-be69-827d1c79fbb6@github.com>

On Mon, 13 Jan 2025 10:42:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to PSStripeShadowCardTable to avoid several examples
>> of UB in it's internal calculations.  We avoid the UB by switching to the
>> integer domain (using uintptr_t) for all of the internal calculations, with
>> casts between pointers and uintptr_t as needed at the boundaries.
>> 
>> This applies not just to the various pointer adjustments, but also to pointer
>> comparisons. In particular, the prior range check assertions using pointer
>> comparisons could have been partially or even completely "optimized" away
>> based on the no-UB assumption.
>> 
>> Testing: mach5 tier1-5
>> local (linux-x64) tier1 with -XX:+UseParallelGC
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo: intptr_t => uintptr_t

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23032#pullrequestreview-2546358162

From ayang at openjdk.org  Mon Jan 13 12:27:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 13 Jan 2025 12:27:44 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds [v2]
In-Reply-To: <H8HZ9Vel9JOJmL1YpyfXX2keqcyGByc07MXnsN0Nnig=.d1928ea1-ee33-4743-9370-014731f357a5@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
 <H8HZ9Vel9JOJmL1YpyfXX2keqcyGByc07MXnsN0Nnig=.d1928ea1-ee33-4743-9370-014731f357a5@github.com>
Message-ID: <ZYg1HDhi4XTmcURWL8gR_tOoiva23cPAvPsdr2--1jk=.9ed78118-9300-43bb-ac22-02c7caa2418a@github.com>

On Mon, 13 Jan 2025 10:42:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to PSStripeShadowCardTable to avoid several examples
>> of UB in it's internal calculations.  We avoid the UB by switching to the
>> integer domain (using uintptr_t) for all of the internal calculations, with
>> casts between pointers and uintptr_t as needed at the boundaries.
>> 
>> This applies not just to the various pointer adjustments, but also to pointer
>> comparisons. In particular, the prior range check assertions using pointer
>> comparisons could have been partially or even completely "optimized" away
>> based on the no-UB assumption.
>> 
>> Testing: mach5 tier1-5
>> local (linux-x64) tier1 with -XX:+UseParallelGC
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo: intptr_t => uintptr_t

src/hotspot/share/gc/parallel/psCardTable.cpp line 149:

> 147:     assert(iaddr(card) >= iaddr(_table), "out of bounds");
> 148:     assert(iaddr(card) <= (iaddr(_table) + sizeof(_table)), "out of bounds");
> 149:   }

The two impls look identical to me. Also, can you change `check` to `verify` to make it more explicit that they are for verification only?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23032#discussion_r1913094129

From kbarrett at openjdk.org  Mon Jan 13 15:19:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 Jan 2025 15:19:52 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds [v2]
In-Reply-To: <ZYg1HDhi4XTmcURWL8gR_tOoiva23cPAvPsdr2--1jk=.9ed78118-9300-43bb-ac22-02c7caa2418a@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
 <H8HZ9Vel9JOJmL1YpyfXX2keqcyGByc07MXnsN0Nnig=.d1928ea1-ee33-4743-9370-014731f357a5@github.com>
 <ZYg1HDhi4XTmcURWL8gR_tOoiva23cPAvPsdr2--1jk=.9ed78118-9300-43bb-ac22-02c7caa2418a@github.com>
Message-ID: <wifmgwB6lalcEPPIvCD78nx0wDhb_dfd2yRisCON_dQ=.9f552007-36e1-4280-854a-85f6c3baf2e7@github.com>

On Mon, 13 Jan 2025 12:12:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo: intptr_t => uintptr_t
>
> src/hotspot/share/gc/parallel/psCardTable.cpp line 149:
> 
>> 147:     assert(iaddr(card) >= iaddr(_table), "out of bounds");
>> 148:     assert(iaddr(card) <= (iaddr(_table) + sizeof(_table)), "out of bounds");
>> 149:   }
> 
> The two impls look identical to me. Also, can you change `check` to `verify` to make it more explicit that they are for verification only?

They certainly used to be different; not sure how that crept in.  I'll push after rerunning tests.
Rename suggestion is fine, and adopted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23032#discussion_r1913358972

From lgxbslgx at gmail.com  Mon Jan 13 15:52:08 2025
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Mon, 13 Jan 2025 23:52:08 +0800
Subject: [Discussion] Serial GC: Expand young generation size
In-Reply-To: <2DB4422C-73F3-4E27-B41B-6028A6BFF51E@kodewerk.com>
References: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>
 <SA3PR10MB7022AB3FB889B4ABF2400E85D3122@SA3PR10MB7022.namprd10.prod.outlook.com>
 <2DB4422C-73F3-4E27-B41B-6028A6BFF51E@kodewerk.com>
Message-ID: <CAPSsVqih4NyY76+1syvCziLhwH4im+gJe6_=6W+atBoC4hkq+Q@mail.gmail.com>

Hi Albert,

Sorry for any delay. I bisect the related patches in several days.

> Re https://bugs.openjdk.org/browse/JDK-8333386, I think your suggestion,
"add the option `-XX:NewSize=65m`", is the way to go.

When I run the test case `TestAbortOnVMOperationTimeout` [1] in current
main-line code,
the test case passed in the client VM. I bisected all the related patches
these months
and found the change (the test case passed) began at JDK-8333786 [2].
Then I tried partial code of JDK-8333786 [2] in its previous patch (the
code is in [3]),
and finally I found the method
`SerialHeap::should_try_older_generation_allocation` [4]
in JDK-8333786 [2] makes the test case pass in the client VM.
It is because such a change can make the
`DefNewGeneration::compute_new_size`
effective, and then the young-gen size can be expanded after the GC.
So I think the JDK-8333386 [1] is not a bug now and the ticket can be
closed.
What do you think about it?

> As for adding young-gen expansion support to Serial, it probably should
have its own enhancement ticket.
>
> I am currently working on placing from/to spaces before eden inside
young-gen as part of Parallel heap-auto-sizing. I believe Serial can use
the same layout (from/to/eden, instead of eden/from/to) to facilitate
eden/young-gen expansion. My 2c.

Yes, the expansion should have its ticket and need more investigation and
discussion. And this email line is the beginning of the discussion.

Best Regards,
-- Guoxiong

[1] https://bugs.openjdk.org/browse/JDK-8333386
[2] https://bugs.openjdk.org/browse/JDK-8333786
<https://bugs.openjdk.org/browse/JDK-8333386>
[3] https://bugs.openjdk.org/browse/JDK-
<https://bugs.openjdk.org/browse/JDK-8333386>8335007
<https://bugs.openjdk.org/browse/JDK-8333386>
[4]
https://github.com/openjdk/jdk/commit/6b961acb87c29027f2158c6b7a764f1276a0bf52#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626R286-R290
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250113/dda4f2d5/attachment.htm>

From wkemper at openjdk.org  Mon Jan 13 18:22:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Jan 2025 18:22:38 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
 <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
Message-ID: <XX_7834Kd34m9LJy58SFTCf9jzXqkOeF4tWNrxubE6w=.97051791-65d7-4358-9855-26b1c1943491@github.com>

On Sat, 11 Jan 2025 01:50:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments and method names
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1245:
> 
>> 1243:   void do_thread(Thread* thread) override {
>> 1244:     _propagator.do_thread(thread);
>> 1245:     if (ShenandoahThreadLocalData::gclab(thread) != nullptr) {
> 
> Which thread may have this be null? (I am looking at the ShenandoahRetireGCLabClosure which insists that this should be non-null.)
> 
> I assume we have some threads here that have a gc state that must be updated but which don't have a gc lab.
> 
> I am wondering if the check for an initialized gclab and in the generational case the plab can be pushed down into the closure rather than being exposed here. At that place, we would want to document (or as needed assert) why some threads targeted by the closure may have null gclab or plab.

Only worker threads and java threads are required to have gclabs. In other use cases (`shHeap::make_labs_parsable`, `shHeap::retire_gclabs`), this closure is _only_ used on java and worker threads, so pushing the test into the closure would be redundant for other uses. I will put in a comment here instead?

Additionally, I noticed an inconsistency between `make_labs_parsable` (which skips the safepoint workers) and `retire_gclabs` (which also visited the control thread). An earlier version of this PR had given gclabs to the control and vm threads, but these threads will only perform evacuations in very rare circumstances, so I've removed their gclabs.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1267:
> 
>> 1265: 
>> 1266:   // This will propagate the gc state and retire gclabs and plabs for threads that require it.
>> 1267:   ShenandoahPrepareForUpdateRefs prepare_for_update_refs(_gc_state.raw_value());
> 
> In looking at this I see that we do not set `_gc_state_changed` here because we don't want individual threads to observe the global state, but only their local state (when it's propagated below). It would be good to emphasise this in the documetation of `_gc_state_changed` use protocol.
> 
> Indeed, as I had suggested before, I think this might be better encapsulated with a `set_gc_state_concurrent()` that is analogous to `set_gc_state_at_safepoint()` that takes the appropriate state value as an argument, and uses the appropriate `_gc_state_changed` protocol.
> 
> IIUC, this will be re-used when other safepoints are eliminated in the future.

I'll encapsulate the access here and improve the documentation for `_gc_state_changed`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1913617339
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1913620624

From wkemper at openjdk.org  Mon Jan 13 18:32:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Jan 2025 18:32:47 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
 <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
Message-ID: <LTgIzUzdrPoC4WiJgIN-V4CIpq2_q64oAGzuzWI4v4E=.94af6f43-83d9-4901-a6bf-cce774312707@github.com>

On Sat, 11 Jan 2025 01:35:06 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments and method names
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 196:
> 
>> 194: 
>> 195:     // Evacuation is complete, retire gc labs
>> 196:     heap->concurrent_prepare_for_update_refs();
> 
> For consistency with other related method naming, can we use "updaterefs" instead of "update_refs" (makes IDE searches easier to locate related methods).

I'm all for making this consistent, but it seems that `update_refs` is more commonly used in method and variable declarations:

[0] % grep -r --include "*.hpp" updaterefs src/hotspot/share/gc/shenandoah | wc -l 
17

[0] % grep -r --include "*.hpp" update_refs src/hotspot/share/gc/shenandoah | wc -l
27

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1913637958

From wkemper at openjdk.org  Mon Jan 13 18:36:44 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Jan 2025 18:36:44 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <LTgIzUzdrPoC4WiJgIN-V4CIpq2_q64oAGzuzWI4v4E=.94af6f43-83d9-4901-a6bf-cce774312707@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
 <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
 <LTgIzUzdrPoC4WiJgIN-V4CIpq2_q64oAGzuzWI4v4E=.94af6f43-83d9-4901-a6bf-cce774312707@github.com>
Message-ID: <ijooSJn48l4FkpeStKFLin5M211W4y9sUaL6pEhqr70=.afee70fb-2fd1-4d52-9986-0e93e0c7fd17@github.com>

On Mon, 13 Jan 2025 18:29:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 196:
>> 
>>> 194: 
>>> 195:     // Evacuation is complete, retire gc labs
>>> 196:     heap->concurrent_prepare_for_update_refs();
>> 
>> For consistency with other related method naming, can we use "updaterefs" instead of "update_refs" (makes IDE searches easier to locate related methods).
>
> I'm all for making this consistent, but it seems that `update_refs` is more commonly used in method and variable declarations:
> 
> [0] % grep -r --include "*.hpp" updaterefs src/hotspot/share/gc/shenandoah | wc -l 
> 17
> 
> [0] % grep -r --include "*.hpp" update_refs src/hotspot/share/gc/shenandoah | wc -l
> 27

If it's okay with you, I will do this on a separate PR so that this current PR is not cluttered by the change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1913642618

From wkemper at openjdk.org  Mon Jan 13 18:45:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Jan 2025 18:45:23 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v4]
In-Reply-To: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
Message-ID: <Gz9tAed5RTkZiXPZJuTqPdnHQfCWyk_9ZF-jlQXdCpA=.42ba8379-5bfb-42fc-8ee9-fc5cee3ea6ab@github.com>

> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
> 
> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
> 
> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.

William Kemper has updated the pull request incrementally with two additional commits since the last revision:

 - Encapsulate and document a method for making concurrent gc_state changes
 - Control thread doesn't need a gc lab, also make gclabs for safepoint workers parsable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22688/files
  - new: https://git.openjdk.org/jdk/pull/22688/files/89c20a14..26e382c5

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

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

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

From wkemper at openjdk.org  Mon Jan 13 18:55:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Jan 2025 18:55:50 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <ijooSJn48l4FkpeStKFLin5M211W4y9sUaL6pEhqr70=.afee70fb-2fd1-4d52-9986-0e93e0c7fd17@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
 <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
 <LTgIzUzdrPoC4WiJgIN-V4CIpq2_q64oAGzuzWI4v4E=.94af6f43-83d9-4901-a6bf-cce774312707@github.com>
 <ijooSJn48l4FkpeStKFLin5M211W4y9sUaL6pEhqr70=.afee70fb-2fd1-4d52-9986-0e93e0c7fd17@github.com>
Message-ID: <aASihkk_IzolDQZay-IsPtK3e_ufF47znuMAdJiRRbw=.23447989-616a-4ed8-8847-ae8410df9b96@github.com>

On Mon, 13 Jan 2025 18:34:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I'm all for making this consistent, but it seems that `update_refs` is more commonly used in method and variable declarations:
>> 
>> [0] % grep -r --include "*.hpp" updaterefs src/hotspot/share/gc/shenandoah | wc -l 
>> 17
>> 
>> [0] % grep -r --include "*.hpp" update_refs src/hotspot/share/gc/shenandoah | wc -l
>> 27
>
> If it's okay with you, I will do this on a separate PR so that this current PR is not cluttered by the change.

https://bugs.openjdk.org/browse/JDK-8347617

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1913666119

From wkemper at openjdk.org  Mon Jan 13 20:13:19 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Jan 2025 20:13:19 GMT
Subject: RFR: 8347620: Shenandoah: Use 'free' tag for free set related logging
Message-ID: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>

Without a distinguishing tag, debug logging is too voluminous to enable when we really only want the free set's debug messages.

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

Commit messages:
 - Use 'free' tag with free set messages

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

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

From gli at openjdk.org  Tue Jan 14 07:55:45 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Jan 2025 07:55:45 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <PaRXnmHZ4_LgNwAEc4_iXP7yEhF-sKy-grtDj_cgfJ0=.69cf7106-064a-46e2-ab39-946d50c0d41f@github.com>
References: <aRbb6qlff3ltLgj23yRDzjItKv-pPPvrg4pq39K24XI=.1d183ad5-c08d-45e0-ab88-c937e9364004@github.com>
 <PaRXnmHZ4_LgNwAEc4_iXP7yEhF-sKy-grtDj_cgfJ0=.69cf7106-064a-46e2-ab39-946d50c0d41f@github.com>
Message-ID: <Jp2iJCmidIHhAyWlhgiaO2fO946SsaTFKkTlzZS0P6I=.f3a6e4c8-9dd0-4a55-9243-6d0f4de8c289@github.com>

On Mon, 13 May 2024 01:57:58 GMT, xiaotaonan <duke at openjdk.org> wrote:

>> Serial: Remove the unused parameter of the method SerialHeap::gc_prologue
>
> @lgxbslgx

@xiaotaonan What about this patch? Kindly ping.

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

PR Comment: https://git.openjdk.org/jdk/pull/19207#issuecomment-2589239444

From albert.m.yang at oracle.com  Tue Jan 14 10:54:04 2025
From: albert.m.yang at oracle.com (Albert Yang)
Date: Tue, 14 Jan 2025 10:54:04 +0000
Subject: [External] : Re: [Discussion] Serial GC: Expand young generation
 size
In-Reply-To: <CAPSsVqih4NyY76+1syvCziLhwH4im+gJe6_=6W+atBoC4hkq+Q@mail.gmail.com>
References: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>
 <SA3PR10MB7022AB3FB889B4ABF2400E85D3122@SA3PR10MB7022.namprd10.prod.outlook.com>
 <2DB4422C-73F3-4E27-B41B-6028A6BFF51E@kodewerk.com>
 <CAPSsVqih4NyY76+1syvCziLhwH4im+gJe6_=6W+atBoC4hkq+Q@mail.gmail.com>
Message-ID: <SA3PR10MB7022173A8D7EDF57BD43E6B8D3182@SA3PR10MB7022.namprd10.prod.outlook.com>

Hi Guoxiong,

Thank you for the archeology work -- seems that the simplification patch "fixes" the failure by accident. Then, JDK-8333386 can be closed as duplicate of  JDK-8333786.

/Albert

________________________________________
From: Guoxiong Li <lgxbslgx at gmail.com>
Sent: Monday, January 13, 2025 16:52
To: Albert Yang
Cc: hotspot-gc-dev at openjdk.org
Subject: [External] : Re: [Discussion] Serial GC: Expand young generation size

Hi Albert,

Sorry for any delay. I bisect the related patches in several days.

> Re https://bugs.openjdk.org/browse/JDK-8333386, I think your suggestion, "add the option `-XX:NewSize=65m`", is the way to go.

When I run the test case `TestAbortOnVMOperationTimeout` [1] in current main-line code,
the test case passed in the client VM. I bisected all the related patches these months
and found the change (the test case passed) began at JDK-8333786 [2].
Then I tried partial code of JDK-8333786 [2] in its previous patch (the code is in [3]),
and finally I found the method `SerialHeap::should_try_older_generation_allocation` [4]
in JDK-8333786 [2] makes the test case pass in the client VM.
It is because such a change can make the `DefNewGeneration::compute_new_size`
effective, and then the young-gen size can be expanded after the GC.
So I think the JDK-8333386 [1] is not a bug now and the ticket can be closed.
What do you think about it?

> As for adding young-gen expansion support to Serial, it probably should have its own enhancement ticket.
>
> I am currently working on placing from/to spaces before eden inside young-gen as part of Parallel heap-auto-sizing. I believe Serial can use the same layout (from/to/eden, instead of eden/from/to) to facilitate eden/young-gen expansion. My 2c.

Yes, the expansion should have its ticket and need more investigation and discussion. And this email line is the beginning of the discussion.

Best Regards,
-- Guoxiong

[1] https://bugs.openjdk.org/browse/JDK-8333386
[2] https://bugs.openjdk.org/browse/JDK-8333786<https://bugs.openjdk.org/browse/JDK-8333386>
[3] https://bugs.openjdk.org/browse/JDK-<https://bugs.openjdk.org/browse/JDK-8333386>8335007<https://bugs.openjdk.org/browse/JDK-8333386>
[4] https://github.com/openjdk/jdk/commit/6b961acb87c29027f2158c6b7a764f1276a0bf52#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626R286-R290<https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/6b961acb87c29027f2158c6b7a764f1276a0bf52*diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626R286-R290__;Iw!!ACWV5N9M2RV99hQ!JnWWR0C3JnxdoXIeJzQ7HWdLm4laX52Yszdkpx2IasRS_5Ang31avM-FcZV0k_fHlZjWK_qD37ldNiyWBZc3$>


From kbarrett at openjdk.org  Tue Jan 14 16:27:13 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Jan 2025 16:27:13 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds [v3]
In-Reply-To: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
Message-ID: <0fqcml_YX_eihw0qPEuNsTPpW2pyvXJJYUZGjyaEutc=.b577fa4e-99a2-45f6-8fed-79fe64f39525@github.com>

> Please review this change to PSStripeShadowCardTable to avoid several examples
> of UB in it's internal calculations.  We avoid the UB by switching to the
> integer domain (using uintptr_t) for all of the internal calculations, with
> casts between pointers and uintptr_t as needed at the boundaries.
> 
> This applies not just to the various pointer adjustments, but also to pointer
> comparisons. In particular, the prior range check assertions using pointer
> comparisons could have been partially or even completely "optimized" away
> based on the no-UB assumption.
> 
> Testing: mach5 tier1-5
> local (linux-x64) tier1 with -XX:+UseParallelGC

Kim Barrett 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:

 - Merge branch 'master' into pscardtable-ubsan
 - fix exclusive check, rename to verify
 - typo: intptr_t => uintptr_t
 - avoid UB

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23032/files
  - new: https://git.openjdk.org/jdk/pull/23032/files/58c704f7..a6dbfeda

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

  Stats: 11917 lines in 695 files changed: 3795 ins; 5185 del; 2937 mod
  Patch: https://git.openjdk.org/jdk/pull/23032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23032/head:pull/23032

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

From ayang at openjdk.org  Tue Jan 14 17:01:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Jan 2025 17:01:52 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds [v3]
In-Reply-To: <0fqcml_YX_eihw0qPEuNsTPpW2pyvXJJYUZGjyaEutc=.b577fa4e-99a2-45f6-8fed-79fe64f39525@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
 <0fqcml_YX_eihw0qPEuNsTPpW2pyvXJJYUZGjyaEutc=.b577fa4e-99a2-45f6-8fed-79fe64f39525@github.com>
Message-ID: <X3SDGSE22QSsxw4ESlaEeeSmXGqYYaZc1-KHRE9KaHE=.36d2dc7b-22f2-433c-977e-a37865d62885@github.com>

On Tue, 14 Jan 2025 16:27:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to PSStripeShadowCardTable to avoid several examples
>> of UB in it's internal calculations.  We avoid the UB by switching to the
>> integer domain (using uintptr_t) for all of the internal calculations, with
>> casts between pointers and uintptr_t as needed at the boundaries.
>> 
>> This applies not just to the various pointer adjustments, but also to pointer
>> comparisons. In particular, the prior range check assertions using pointer
>> comparisons could have been partially or even completely "optimized" away
>> based on the no-UB assumption.
>> 
>> Testing: mach5 tier1-5
>> local (linux-x64) tier1 with -XX:+UseParallelGC
>
> Kim Barrett 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:
> 
>  - Merge branch 'master' into pscardtable-ubsan
>  - fix exclusive check, rename to verify
>  - typo: intptr_t => uintptr_t
>  - avoid UB

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23032#pullrequestreview-2550445506

From coleenp at openjdk.org  Tue Jan 14 18:45:27 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 18:45:27 GMT
Subject: RFR: 8347730: Replace SIZE_FORMAT in g1
Message-ID: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>

Please review this change to replace SIZE_FORMAT with %zu in the g1 directory.  Most edits were by script but SIZE_FORMAT_W(n) was done sort of by hand.  Also fixed one place where preexisting formatting was bad.

Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

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

Commit messages:
 - Fix squished message.
 - Replace SIZE_FORMAT in g1 gc

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

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

From kbarrett at openjdk.org  Tue Jan 14 18:57:54 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Jan 2025 18:57:54 GMT
Subject: RFR: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large
 index is out of bounds [v2]
In-Reply-To: <7sweSVqwZcmnqFepnd4Cnl9nJCbuIfreU-mZt3n0a6I=.695c61d4-b2e3-4bc0-be69-827d1c79fbb6@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
 <H8HZ9Vel9JOJmL1YpyfXX2keqcyGByc07MXnsN0Nnig=.d1928ea1-ee33-4743-9370-014731f357a5@github.com>
 <7sweSVqwZcmnqFepnd4Cnl9nJCbuIfreU-mZt3n0a6I=.695c61d4-b2e3-4bc0-be69-827d1c79fbb6@github.com>
Message-ID: <OeimrRz7CscblbB52D5WqPny8Z6nbKZMbRNKZgfZoAI=.4f2225b3-41e3-481b-bb7e-baeb9060657e@github.com>

On Mon, 13 Jan 2025 11:27:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo: intptr_t => uintptr_t
>
> Lgtm.

Thanks for reviews @tschatzl and @albertnetymk

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

PR Comment: https://git.openjdk.org/jdk/pull/23032#issuecomment-2590874334

From kbarrett at openjdk.org  Tue Jan 14 18:57:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Jan 2025 18:57:55 GMT
Subject: Integrated: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error:
 large index is out of bounds
In-Reply-To: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
References: <9z8Cc4DgoD1x5QsvkcW6SptNYlEsiAr2V8M5eWvt7gk=.30a3dd75-782e-4a1c-86d9-08449c8c7d93@github.com>
Message-ID: <Z8i5pH5QIU1huyioYkI3iPR6pARLSQ7YhnVoNNXna_w=.9967f54e-c48a-44f6-8b26-7012231b1683@github.com>

On Fri, 10 Jan 2025 11:21:31 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to PSStripeShadowCardTable to avoid several examples
> of UB in it's internal calculations.  We avoid the UB by switching to the
> integer domain (using uintptr_t) for all of the internal calculations, with
> casts between pointers and uintptr_t as needed at the boundaries.
> 
> This applies not just to the various pointer adjustments, but also to pointer
> comparisons. In particular, the prior range check assertions using pointer
> comparisons could have been partially or even completely "optimized" away
> based on the no-UB assumption.
> 
> Testing: mach5 tier1-5
> local (linux-x64) tier1 with -XX:+UseParallelGC

This pull request has now been integrated.

Changeset: 4c30933b
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c30933b2ab92369d2da449ab3cd030b748e61fb
Stats:     35 lines in 1 file changed: 29 ins; 0 del; 6 mod

8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large index is out of bounds

Reviewed-by: ayang, tschatzl

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

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

From ayang at openjdk.org  Tue Jan 14 19:22:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Jan 2025 19:22:42 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <jvapQiGl_Lr7XQm8mB64bTIobUNNd8Ml1KjQR9n80kI=.12e9673d-0784-47ea-90d1-35357271c8a3@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2550823927

From xpeng at openjdk.org  Tue Jan 14 19:25:16 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 14 Jan 2025 19:25:16 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v6]
In-Reply-To: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
Message-ID: <I6TNL4ShN1Ta0WVS2xmWsu7CYt4A5e4MiiyqnqS71d8=.10f37616-20b1-4234-b80c-a07520d60518@github.com>

> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
> 
> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
> 
> GenShen:
> Before:
> 
> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
> 
> 
> After:
> 
> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
> 
> 
> Shenandoah:
> Before:
> 
> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
> 
> After:
> 
> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
> 
> 
> Additional changes:
> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
> * Clean up FullGC code, remove duplicate code.
> 
> Additional tests:
> - [x] CONF=macosx-aarch64-server-fastdebug make test T...

Xiaolong Peng 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 22 additional commits since the last revision:

 - Merge branch 'openjdk:master' into reset-bitmap
 - Merge branch 'openjdk:master' into reset-bitmap
 - Adding condition "!_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress()" back and address some PR comments
 - Remove entry_reset_after_collect from ShenandoahOldGC
 - Remove condition check !_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress() from op_reset_after_collect
 - Merge branch 'openjdk:master' into reset-bitmap
 - Address review comments
 - Merge branch 'openjdk:master' into reset-bitmap
 - Remove ShenandoahResetUpdateRegionStateClosure
 - Always set_mark_incomplete when reset mark bitmap
 - ... and 12 more: https://git.openjdk.org/jdk/compare/4692634b...9e7f342d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22778/files
  - new: https://git.openjdk.org/jdk/pull/22778/files/5a181473..9e7f342d

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

  Stats: 10312 lines in 616 files changed: 3431 ins; 3917 del; 2964 mod
  Patch: https://git.openjdk.org/jdk/pull/22778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22778/head:pull/22778

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

From ysr at openjdk.org  Tue Jan 14 19:42:43 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 14 Jan 2025 19:42:43 GMT
Subject: RFR: 8347620: Shenandoah: Use 'free' tag for free set related
 logging
In-Reply-To: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>
References: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>
Message-ID: <9JVPoK0R2zACoySOT5h_uCekBiY7qm0ym53ybXK9ZwM=.5dc1a715-0093-4896-8ab2-bd3a68aca0b6@github.com>

On Mon, 13 Jan 2025 20:07:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Without a distinguishing tag, debug logging is too voluminous to enable when we really only want the free set's debug messages.

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23086#pullrequestreview-2550863968

From ysr at openjdk.org  Tue Jan 14 20:29:28 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 14 Jan 2025 20:29:28 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v4]
In-Reply-To: <Gz9tAed5RTkZiXPZJuTqPdnHQfCWyk_9ZF-jlQXdCpA=.42ba8379-5bfb-42fc-8ee9-fc5cee3ea6ab@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <Gz9tAed5RTkZiXPZJuTqPdnHQfCWyk_9ZF-jlQXdCpA=.42ba8379-5bfb-42fc-8ee9-fc5cee3ea6ab@github.com>
Message-ID: <mCiKH2jz-RlwSSewRvRfpzVv3CHvcAuUpNeNyRVKvFM=.73a8bee2-ba24-4315-9f25-07e725aa0334@github.com>

On Mon, 13 Jan 2025 18:45:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
>> 
>> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
>> 
>> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Encapsulate and document a method for making concurrent gc_state changes
>  - Control thread doesn't need a gc lab, also make gclabs for safepoint workers parsable

Left a few comments/questions. Looks good modulo those comments. Thanks again for your patience. Rest looks good. No need for a further round from me even if you make further changes in response to my comments.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1268:

> 1266: 
> 1267:   // The handshake won't touch non-java threads, so do those separately.
> 1268:   Threads::non_java_threads_do(&prepare_for_update_refs);

Which non-Java threads need to prepare for update refs? (i.e. which make use of this state predicate and/or participate in update refs phase.)

Would be good to document that somewhere (or may be repeat it here).

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 372:

> 370:   // Critically, this method will _not_ flag that the global gc state has changed and threads
> 371:   // will continue to use their thread local copy. This is expected to be used in conjunction
> 372:   // with a handshake operation to propagate the new gc state.

Thank you for this comment!

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22688#pullrequestreview-2550382471
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1915539302
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1915543381

From ysr at openjdk.org  Tue Jan 14 20:29:29 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 14 Jan 2025 20:29:29 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <aASihkk_IzolDQZay-IsPtK3e_ufF47znuMAdJiRRbw=.23447989-616a-4ed8-8847-ae8410df9b96@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
 <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
 <LTgIzUzdrPoC4WiJgIN-V4CIpq2_q64oAGzuzWI4v4E=.94af6f43-83d9-4901-a6bf-cce774312707@github.com>
 <ijooSJn48l4FkpeStKFLin5M211W4y9sUaL6pEhqr70=.afee70fb-2fd1-4d52-9986-0e93e0c7fd17@github.com>
 <aASihkk_IzolDQZay-IsPtK3e_ufF47znuMAdJiRRbw=.23447989-616a-4ed8-8847-ae8410df9b96@github.com>
Message-ID: <cCT78mDvKLG5coJAW0f0aCX6xsyJ8BaGfoMInlrjpmk=.20865491-7233-4f80-9942-9d0d8e4a8ba3@github.com>

On Mon, 13 Jan 2025 18:53:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> If it's okay with you, I will do this on a separate PR so that this current PR is not cluttered by the change.
>
> https://bugs.openjdk.org/browse/JDK-8347617

Yes, that's OK. I didn't realize there were so many `update_refs` and `updaterefs` each... I had only looked at the `[[[vm_]op_]init_updaterefs}` class of names (including the ones right below here) and incorrectly assumed there was consistency in the naming, but for this new variant that you had introduced in this PR.

Thanks for filing a separate ticket for rename, and it makes sense to do that kind of wholesale renaming later. (The suggestion here had been just for this name, but I see that it isn't inconsistent with the lack of a single convention, so I take back my comment.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1915221534

From ysr at openjdk.org  Tue Jan 14 20:29:31 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 14 Jan 2025 20:29:31 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <XX_7834Kd34m9LJy58SFTCf9jzXqkOeF4tWNrxubE6w=.97051791-65d7-4358-9855-26b1c1943491@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
 <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
 <XX_7834Kd34m9LJy58SFTCf9jzXqkOeF4tWNrxubE6w=.97051791-65d7-4358-9855-26b1c1943491@github.com>
Message-ID: <qOwQ3vbIIAyQ171Xrw7Z6gI4Cg_sDgbuF4vNU2yD9fA=.f71b59d4-99ac-4fc0-a4cf-66e9823dd276@github.com>

On Mon, 13 Jan 2025 18:18:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1245:
>> 
>>> 1243:   void do_thread(Thread* thread) override {
>>> 1244:     _propagator.do_thread(thread);
>>> 1245:     if (ShenandoahThreadLocalData::gclab(thread) != nullptr) {
>> 
>> Which thread may have this be null? (I am looking at the ShenandoahRetireGCLabClosure which insists that this should be non-null.)
>> 
>> I assume we have some threads here that have a gc state that must be updated but which don't have a gc lab.
>> 
>> I am wondering if the check for an initialized gclab and in the generational case the plab can be pushed down into the closure rather than being exposed here. At that place, we would want to document (or as needed assert) why some threads targeted by the closure may have null gclab or plab.
>
> Only worker threads and java threads are required to have gclabs. In other use cases (`shHeap::make_labs_parsable`, `shHeap::retire_gclabs`), this closure is _only_ used on java and worker threads, so pushing the test into the closure would be redundant for other uses. I will put in a comment here instead?
> 
> Additionally, I noticed an inconsistency between `make_labs_parsable` (which skips the safepoint workers) and `retire_gclabs` (which also visited the control thread). An earlier version of this PR had given gclabs to the control and vm threads, but these threads will only perform evacuations in very rare circumstances, so I've removed their gclabs.

Para 1: Yes, that makes sense.

Para 2: I am not sure I follow. Don't we need to cover the _rare_ case where these threads _have_ a gc lab? I agree that the control and vm threads should not need to participate in actual copying work. What is the rare circumstance in which they do need to?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1915522467

From ysr at openjdk.org  Tue Jan 14 20:29:31 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 14 Jan 2025 20:29:31 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <qOwQ3vbIIAyQ171Xrw7Z6gI4Cg_sDgbuF4vNU2yD9fA=.f71b59d4-99ac-4fc0-a4cf-66e9823dd276@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
 <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
 <XX_7834Kd34m9LJy58SFTCf9jzXqkOeF4tWNrxubE6w=.97051791-65d7-4358-9855-26b1c1943491@github.com>
 <qOwQ3vbIIAyQ171Xrw7Z6gI4Cg_sDgbuF4vNU2yD9fA=.f71b59d4-99ac-4fc0-a4cf-66e9823dd276@github.com>
Message-ID: <_RgeGbJFHlhopi8O5jrLrc14uvEyyREpLzUkS2ClD38=.91f8a9dc-5cd3-4fd6-824a-46a772fab040@github.com>

On Tue, 14 Jan 2025 19:56:25 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Only worker threads and java threads are required to have gclabs. In other use cases (`shHeap::make_labs_parsable`, `shHeap::retire_gclabs`), this closure is _only_ used on java and worker threads, so pushing the test into the closure would be redundant for other uses. I will put in a comment here instead?
>> 
>> Additionally, I noticed an inconsistency between `make_labs_parsable` (which skips the safepoint workers) and `retire_gclabs` (which also visited the control thread). An earlier version of this PR had given gclabs to the control and vm threads, but these threads will only perform evacuations in very rare circumstances, so I've removed their gclabs.
>
> Para 1: Yes, that makes sense.
> 
> Para 2: I am not sure I follow. Don't we need to cover the _rare_ case where these threads _have_ a gc lab? I agree that the control and vm threads should not need to participate in actual copying work. What is the rare circumstance in which they do need to?

Do control/regulator/vm thread need a local GC state, if they never use an LRB that needs to consult local state? (vide my comment at line 1268 below).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1915540368

From wkemper at openjdk.org  Tue Jan 14 21:10:48 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 14 Jan 2025 21:10:48 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v3]
In-Reply-To: <_RgeGbJFHlhopi8O5jrLrc14uvEyyREpLzUkS2ClD38=.91f8a9dc-5cd3-4fd6-824a-46a772fab040@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <A2jbMuYx4J2R75qiQ4QkmhI4jHC-L36PsCCQsz_S9RM=.5e010092-2c86-445d-bcef-364d58ffba74@github.com>
 <2smNeh6fdjcA_HtcFLFy9IqJBFETW_CRnqzyW1Z7rbI=.8bd30d87-3602-42cd-9f54-c0b818446e7d@github.com>
 <XX_7834Kd34m9LJy58SFTCf9jzXqkOeF4tWNrxubE6w=.97051791-65d7-4358-9855-26b1c1943491@github.com>
 <qOwQ3vbIIAyQ171Xrw7Z6gI4Cg_sDgbuF4vNU2yD9fA=.f71b59d4-99ac-4fc0-a4cf-66e9823dd276@github.com>
 <_RgeGbJFHlhopi8O5jrLrc14uvEyyREpLzUkS2ClD38=.91f8a9dc-5cd3-4fd6-824a-46a772fab040@github.com>
Message-ID: <mSePBp4sq9Km4oaWiORqGo49Arcl8tPFO49jJ2rM_mY=.665b3250-0e0f-468d-b0a3-00e2381742da@github.com>

On Tue, 14 Jan 2025 20:13:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Para 1: Yes, that makes sense.
>> 
>> Para 2: I am not sure I follow. Don't we need to cover the _rare_ case where these threads _have_ a gc lab? I agree that the control and vm threads should not need to participate in actual copying work. What is the rare circumstance in which they do need to?
>
> Do control/regulator/vm thread need a local GC state, if they never use an LRB that needs to consult local state? (vide my comment at line 1268 below).

The control thread runs the final steps of concurrent reference processing in which the list of references that have been cleared is constructed and published to a reference in the heap (see Universe::_reference_pending_list). The VM thread may also need to evacuate objects when a heap dump is taken during the concurrent evacuation phase. When the heap dump is taken by parallel threads, it will use the worker threads and these _will_ have `gclabs`. However, in some cases, the VM thread itself will walk the heap and perform evacuations. In these cases when the VM thread or control thread evacuate objects, they will fallback to `shared` allocations. These two threads still execute the load-reference-barrier and need a local GC state (possibly the VM thread would not need it, but I'm erring on the side of caution).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1915600281

From stefank at openjdk.org  Tue Jan 14 21:11:34 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 14 Jan 2025 21:11:34 GMT
Subject: RFR: 8347729: Replace SIZE_FORMAT in parallel and serial gc
In-Reply-To: <xqNbKd-jfNFCgJRbuCdUG0KAIehPPgrWuJmOZ_oW6OI=.edc7b222-6d31-48c6-9c2f-ecec51b28829@github.com>
References: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
 <xqNbKd-jfNFCgJRbuCdUG0KAIehPPgrWuJmOZ_oW6OI=.edc7b222-6d31-48c6-9c2f-ecec51b28829@github.com>
Message-ID: <hI1kBurqPcEh7pFjCU32fP85-THKWdJ-eE--fnIzVss=.d4a1927b-98a3-4a3f-8abe-719dabb06896@github.com>

On Tue, 14 Jan 2025 18:16:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the parallel and serial gc directories. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  The %zu is a lot less noisy but it does look funny as %zums.  I verified that this format specifier does print <the number>ms and doesn't get confused.
>> 
>> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.
>
> (so I get the email)

@coleenp Your manual label addition prevents skara from adding the hotspot-gc label

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

PR Comment: https://git.openjdk.org/jdk/pull/23113#issuecomment-2591106831

From wkemper at openjdk.org  Tue Jan 14 21:16:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 14 Jan 2025 21:16:41 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v4]
In-Reply-To: <mCiKH2jz-RlwSSewRvRfpzVv3CHvcAuUpNeNyRVKvFM=.73a8bee2-ba24-4315-9f25-07e725aa0334@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <Gz9tAed5RTkZiXPZJuTqPdnHQfCWyk_9ZF-jlQXdCpA=.42ba8379-5bfb-42fc-8ee9-fc5cee3ea6ab@github.com>
 <mCiKH2jz-RlwSSewRvRfpzVv3CHvcAuUpNeNyRVKvFM=.73a8bee2-ba24-4315-9f25-07e725aa0334@github.com>
Message-ID: <wP4SxE6XE_pt7RbxwRdN2ytzQ2w7RYDGtWqgOSpQWzc=.4d2dcc85-0028-49d7-9806-6dd4df155cef@github.com>

On Tue, 14 Jan 2025 20:12:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Encapsulate and document a method for making concurrent gc_state changes
>>  - Control thread doesn't need a gc lab, also make gclabs for safepoint workers parsable
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1268:
> 
>> 1266: 
>> 1267:   // The handshake won't touch non-java threads, so do those separately.
>> 1268:   Threads::non_java_threads_do(&prepare_for_update_refs);
> 
> Which non-Java threads need to prepare for update refs? (i.e. which make use of this state predicate and/or participate in update refs phase.)
> 
> Would be good to document that somewhere (or may be repeat it here).

I will change the comment here. Specifically, we are most interested in changing the gc state for the worker threads, but also the control thread and vm thread and any other thread that might touch an oop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1915606414

From wkemper at openjdk.org  Tue Jan 14 21:23:32 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 14 Jan 2025 21:23:32 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v5]
In-Reply-To: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
Message-ID: <MPVHAegC_cUFcLdi4Iduco9sVfTyZKU-agwiBigCorw=.6bd364c7-d291-47ee-9b5a-73c508d57f62@github.com>

> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
> 
> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
> 
> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.

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 37 additional commits since the last revision:

 - Call out the non-java threads we are most concerned with in the comment
 - Merge tag 'jdk-25+5' into remove-init-update-refs-safepoint
   
   Added tag jdk-25+5 for changeset 2e00816a
 - Encapsulate and document a method for making concurrent gc_state changes
 - Control thread doesn't need a gc lab, also make gclabs for safepoint workers parsable
 - Improve comments and method names
 - Improve comments
 - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
 - Fix comments
 - Fix comment, revert unnecessary change
 - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
 - ... and 27 more: https://git.openjdk.org/jdk/compare/f8756114...ab808a11

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22688/files
  - new: https://git.openjdk.org/jdk/pull/22688/files/26e382c5..ab808a11

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

  Stats: 11635 lines in 155 files changed: 1555 ins; 9249 del; 831 mod
  Patch: https://git.openjdk.org/jdk/pull/22688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22688/head:pull/22688

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

From wkemper at openjdk.org  Tue Jan 14 23:16:12 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 14 Jan 2025 23:16:12 GMT
Subject: RFR: 8347620: Shenandoah: Use 'free' tag for free set related
 logging [v2]
In-Reply-To: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>
References: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>
Message-ID: <mWcYftmKeSSJEm8EjeImCyiu2QItqUZcDuLhrqq_UuA=.c2d42928-a029-4884-9874-c7c0caf8a3e8@github.com>

> Without a distinguishing tag, debug logging is too voluminous to enable when we really only want the free set's debug messages.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into freeset-debug-instrumentation
 - Use 'free' tag with free set messages

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

Changes: https://git.openjdk.org/jdk/pull/23086/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23086&range=01
  Stats: 81 lines in 1 file changed: 10 ins; 7 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/23086.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23086/head:pull/23086

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

From wkemper at openjdk.org  Tue Jan 14 23:19:49 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 14 Jan 2025 23:19:49 GMT
Subject: RFR: 8347620: Shenandoah: Use 'free' tag for free set related
 logging [v3]
In-Reply-To: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>
References: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>
Message-ID: <kQa86cLhcNw5JSPCgcdL5LHuLpd-v3m0Xwn8jwcajHo=.fbc777fe-5ee8-4cdc-aa07-84722052c151@github.com>

> Without a distinguishing tag, debug logging is too voluminous to enable when we really only want the free set's debug messages.

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge mishap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23086/files
  - new: https://git.openjdk.org/jdk/pull/23086/files/6e04148c..2b613a82

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

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

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

From ysr at openjdk.org  Wed Jan 15 01:18:36 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 15 Jan 2025 01:18:36 GMT
Subject: RFR: 8347620: Shenandoah: Use 'free' tag for free set related
 logging [v3]
In-Reply-To: <kQa86cLhcNw5JSPCgcdL5LHuLpd-v3m0Xwn8jwcajHo=.fbc777fe-5ee8-4cdc-aa07-84722052c151@github.com>
References: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>
 <kQa86cLhcNw5JSPCgcdL5LHuLpd-v3m0Xwn8jwcajHo=.fbc777fe-5ee8-4cdc-aa07-84722052c151@github.com>
Message-ID: <yNFw-Eg6q4j3JX1JhSPcq7Jfa1iHGZbD8ZRo88cNSvM=.0b978eb7-ab46-4681-8806-ac407614b0bb@github.com>

On Tue, 14 Jan 2025 23:19:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Without a distinguishing tag, debug logging is too voluminous to enable when we really only want the free set's debug messages.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge mishap

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23086#pullrequestreview-2551374438

From wkemper at openjdk.org  Wed Jan 15 01:30:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Jan 2025 01:30:41 GMT
Subject: Integrated: 8347620: Shenandoah: Use 'free' tag for free set related
 logging
In-Reply-To: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>
References: <u-Cp3X25j-EMOaiEleyrKtpHBi98tP5ixYfjOhyaFA4=.2978bece-c261-4f5e-8725-853120783613@github.com>
Message-ID: <Hp04kGPiK16zort8KXQdttCxp8VPZQjqiuESHEY6NJU=.590bd038-1443-4fd3-b3c5-5fea95d635c6@github.com>

On Mon, 13 Jan 2025 20:07:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Without a distinguishing tag, debug logging is too voluminous to enable when we really only want the free set's debug messages.

This pull request has now been integrated.

Changeset: 9782bfdd
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9782bfdd27da95c3bab9da6d46d695e717f465d8
Stats:     78 lines in 1 file changed: 7 ins; 7 del; 64 mod

8347620: Shenandoah: Use 'free' tag for free set related logging

Reviewed-by: ysr

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

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

From dholmes at openjdk.org  Wed Jan 15 07:19:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Jan 2025 07:19:23 GMT
Subject: RFR: 8347729: Replace SIZE_FORMAT in parallel and serial gc
In-Reply-To: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
References: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
Message-ID: <z9QUMjH6TDS6T6Btj4cuAvPAhiwwPi_9XRvM8PUHx2E=.0f79f872-9452-4140-8c08-791582e830df@github.com>

On Tue, 14 Jan 2025 18:15:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the parallel and serial gc directories. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  The %zu is a lot less noisy but it does look funny as %zums.  I verified that this format specifier does print <the number>ms and doesn't get confused.
> 
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

LGTM.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23113#pullrequestreview-2551710296

From dholmes at openjdk.org  Wed Jan 15 07:19:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Jan 2025 07:19:29 GMT
Subject: RFR: 8347727: Replace SIZE_FORMAT in shared gc
In-Reply-To: <gA2TqPUv-8zLslulI25W-1kjUTjN-O_QgKzdpoQPEas=.1b6ead58-719c-4f91-9911-01cfb2a3ea93@github.com>
References: <gA2TqPUv-8zLslulI25W-1kjUTjN-O_QgKzdpoQPEas=.1b6ead58-719c-4f91-9911-01cfb2a3ea93@github.com>
Message-ID: <M7W5CXO6C2Akq7ucxhyzL6gTN3SYvbSSgPXWn0WrG44=.05074848-727c-41ae-8cd3-de9b571cb45f@github.com>

On Tue, 14 Jan 2025 17:11:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the shared gc directory.  Most replacements were done with a script but I had a hand-edit in TaskQueueStats.
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

LGTM2

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23111#pullrequestreview-2551703075

From tschatzl at openjdk.org  Wed Jan 15 09:18:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Jan 2025 09:18:35 GMT
Subject: RFR: 8347729: Replace SIZE_FORMAT in parallel and serial gc
In-Reply-To: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
References: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
Message-ID: <C3xhFHalgvmh4OJKUtNK95ZM82tUtuuDK1dvhps8olg=.1957a3ab-d392-4b3b-8d08-0f1692bf175a@github.com>

On Tue, 14 Jan 2025 18:15:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the parallel and serial gc directories. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  The %zu is a lot less noisy but it does look funny as %zums.  I verified that this format specifier does print <the number>ms and doesn't get confused.
> 
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23113#pullrequestreview-2551984959

From tschatzl at openjdk.org  Wed Jan 15 09:37:37 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Jan 2025 09:37:37 GMT
Subject: RFR: 8347730: Replace SIZE_FORMAT in g1
In-Reply-To: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
References: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
Message-ID: <fHHkh2S9-kBg8eR-W5Ctxy-ZLRdhjieECNtrAQqnlzQ=.138d59ea-aeec-425a-a912-d7ccf356fa80@github.com>

On Tue, 14 Jan 2025 18:40:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the g1 directory.  Most edits were by script but SIZE_FORMAT_W(n) was done sort of by hand.  Also fixed one place where preexisting formatting was bad.
> 
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23114#pullrequestreview-2552036460

From tschatzl at openjdk.org  Wed Jan 15 09:40:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Jan 2025 09:40:40 GMT
Subject: RFR: 8347727: Replace SIZE_FORMAT in shared gc
In-Reply-To: <gA2TqPUv-8zLslulI25W-1kjUTjN-O_QgKzdpoQPEas=.1b6ead58-719c-4f91-9911-01cfb2a3ea93@github.com>
References: <gA2TqPUv-8zLslulI25W-1kjUTjN-O_QgKzdpoQPEas=.1b6ead58-719c-4f91-9911-01cfb2a3ea93@github.com>
Message-ID: <tVYUqqFxeDgsC-GKcJc9AoF0wBjkBExQ7sEGFd_4WdY=.9b25c027-28b0-4acd-ad36-8f03d770224b@github.com>

On Tue, 14 Jan 2025 17:11:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the shared gc directory.  Most replacements were done with a script but I had a hand-edit in TaskQueueStats.
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23111#pullrequestreview-2552044133

From tschatzl at openjdk.org  Wed Jan 15 09:50:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Jan 2025 09:50:46 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <0iii5xOCqc5Y4o6SpUIX11dKYjDwFDP7qAyRJ7cgSDM=.f5551a2a-4b1b-4084-b4ee-5b84b417ca4e@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2552068102

From mdoerr at openjdk.org  Wed Jan 15 10:08:45 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Jan 2025 10:08:45 GMT
Subject: Withdrawn: 8347717: Small MaxHeapSize gets increased a lot on platform
 with large page size
In-Reply-To: <n9q3W3Xn44UG-nrECmhOrkqcZh-W1gSKZ7G80AW9n8M=.3296fc21-d0e5-4842-a932-fae7d38ed788@github.com>
References: <n9q3W3Xn44UG-nrECmhOrkqcZh-W1gSKZ7G80AW9n8M=.3296fc21-d0e5-4842-a932-fae7d38ed788@github.com>
Message-ID: <ZgAwfHbYuvx9sh-eDVGCRouVuQ0TFBPhZGdnIyS0ADs=.ecfe691b-67ea-4c82-9c70-705d8c6545e0@github.com>

On Tue, 14 Jan 2025 16:01:42 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> `GCArguments::compute_heap_alignment()` is currently problematic for platforms with large page size. E.g. on PPC64 with 64k pages:
> `java -XX:+PrintFlagsFinal -Xmx8m -version |grep -E "GCCardSizeInBytes|MaxHeapSize"` says:
> 
>      uint GCCardSizeInBytes                        = 512                                       {product} {default}
>    size_t MaxHeapSize                              = 33554432                                  {product} {command line, ergonomic}
>    size_t SoftMaxHeapSize                          = 33554432                               {manageable} {ergonomic}
> openjdk version "25-internal" 2025-09-16
> 
> 
> 
> I suggest to adapt `GCCardSizeInBytes` such that we get the following in this case:
> 
>      uint GCCardSizeInBytes                        = 128                                       {product} {ergonomic}
>    size_t MaxHeapSize                              = 8388608                                   {product} {command line}
>    size_t SoftMaxHeapSize                          = 8388608                                {manageable} {ergonomic}
> 
> 
> Please review. Are there good alternatives / other proposals?

This pull request has been closed without being integrated.

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

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

From coleenp at openjdk.org  Wed Jan 15 12:20:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 12:20:36 GMT
Subject: RFR: 8347729: Replace SIZE_FORMAT in parallel and serial gc
In-Reply-To: <xqNbKd-jfNFCgJRbuCdUG0KAIehPPgrWuJmOZ_oW6OI=.edc7b222-6d31-48c6-9c2f-ecec51b28829@github.com>
References: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
 <xqNbKd-jfNFCgJRbuCdUG0KAIehPPgrWuJmOZ_oW6OI=.edc7b222-6d31-48c6-9c2f-ecec51b28829@github.com>
Message-ID: <b1kwuCm_DCxgcz_sVlRZPDfoOR4O5BP3i4uchmLYcu4=.89189a0a-3215-409e-b987-eb366e3b558f@github.com>

On Tue, 14 Jan 2025 18:16:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the parallel and serial gc directories. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  The %zu is a lot less noisy but it does look funny as %zums.  I verified that this format specifier does print <the number>ms and doesn't get confused.
>> 
>> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.
>
> (so I get the email)

> @coleenp Your manual label addition prevents skara from adding the hotspot-gc label
I didn't know that.  Thanks for adding the GC label.

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

PR Comment: https://git.openjdk.org/jdk/pull/23113#issuecomment-2592643989

From coleenp at openjdk.org  Wed Jan 15 12:28:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 12:28:38 GMT
Subject: RFR: 8347729: Replace SIZE_FORMAT in parallel and serial gc
In-Reply-To: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
References: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
Message-ID: <Id96cWG3pORH88zuBLZ7O6JgMYXCpgbKdjSCNEQrRSU=.866a4d91-8cf2-407a-9091-c4f46c8f32ae@github.com>

On Tue, 14 Jan 2025 18:15:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the parallel and serial gc directories. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  The %zu is a lot less noisy but it does look funny as %zums.  I verified that this format specifier does print <the number>ms and doesn't get confused.
> 
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

Thanks for reviewing David and Thomas.

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

PR Comment: https://git.openjdk.org/jdk/pull/23113#issuecomment-2592669229

From coleenp at openjdk.org  Wed Jan 15 12:28:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 12:28:39 GMT
Subject: Integrated: 8347729: Replace SIZE_FORMAT in parallel and serial gc
In-Reply-To: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
References: <ofpu1SW9PpqnulWjlC9ni2KKlcz0xbQbjIq3YSNXFes=.aa33f70e-e9df-42f2-af49-368b9460e370@github.com>
Message-ID: <cxAo6Gb0pdXYoyQEo4YQwNML8rofMRw55X0r9lvhFTA=.b3b49053-d0c4-48fc-9900-8ed0c0b25e17@github.com>

On Tue, 14 Jan 2025 18:15:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the parallel and serial gc directories. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  The %zu is a lot less noisy but it does look funny as %zums.  I verified that this format specifier does print <the number>ms and doesn't get confused.
> 
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

This pull request has now been integrated.

Changeset: b0e2be6f
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0e2be6f6b668ec4e3cfa525c660193dfbff77bf
Stats:     122 lines in 17 files changed: 0 ins; 1 del; 121 mod

8347729: Replace SIZE_FORMAT in parallel and serial gc

Reviewed-by: dholmes, tschatzl

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

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

From coleenp at openjdk.org  Wed Jan 15 12:59:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 12:59:44 GMT
Subject: RFR: 8347731: Replace SIZE_FORMAT in zgc
Message-ID: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>

Please review this change to replace SIZE_FORMAT with %zu in the zgc directory. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  There's a %zx in this change which I carefully made 0x%zx rather than %#zx.
Tested with tier1-4 with the other GC changes.

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

Commit messages:
 - Replace SIZE_FORMAT in zgc gc

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

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

From coleenp at openjdk.org  Wed Jan 15 13:10:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 13:10:00 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah
Message-ID: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>

Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
Tested with building shenandoah and tier1-4.

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

Commit messages:
 - Add Oracle copyrights.
 - Replace SIZE_FORMAT in shenandoah gc

Changes: https://git.openjdk.org/jdk/pull/23134/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23134&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347732
  Stats: 335 lines in 45 files changed: 35 ins; 0 del; 300 mod
  Patch: https://git.openjdk.org/jdk/pull/23134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23134/head:pull/23134

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

From coleenp at openjdk.org  Wed Jan 15 13:17:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 13:17:04 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah
In-Reply-To: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
Message-ID: <XmxQ3r4KLJwulPWodlD64mFJ0jSxkwTGyoyjsJXIabI=.0b1829dd-8cf9-41ad-9504-6a9be3aa5e41@github.com>

On Wed, 15 Jan 2025 13:03:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
> Tested with building shenandoah and tier1-4.

I hand merged shenandoahFreeSet.cpp also, please review that.

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

PR Comment: https://git.openjdk.org/jdk/pull/23134#issuecomment-2592827927

From coleenp at openjdk.org  Wed Jan 15 13:17:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 13:17:04 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v2]
In-Reply-To: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
Message-ID: <ZbIg252g6wt2xqM7_3OqC8qgyhmLIbe-3rXlaxTFF7I=.06acf0c0-2869-45e3-8ec0-5434b962ab0b@github.com>

> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
> Tested with building shenandoah and tier1-4.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into zmod-shenandoah
 - Add Oracle copyrights.
 - Replace SIZE_FORMAT in shenandoah gc

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

Changes: https://git.openjdk.org/jdk/pull/23134/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23134&range=01
  Stats: 341 lines in 45 files changed: 40 ins; 0 del; 301 mod
  Patch: https://git.openjdk.org/jdk/pull/23134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23134/head:pull/23134

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

From coleenp at openjdk.org  Wed Jan 15 13:24:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 13:24:19 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
Message-ID: <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>

> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
> Tested with building shenandoah and tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23134/files
  - new: https://git.openjdk.org/jdk/pull/23134/files/e0a5f03e..4485fba2

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

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

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

From ysr at openjdk.org  Wed Jan 15 15:58:45 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 15 Jan 2025 15:58:45 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v5]
In-Reply-To: <MPVHAegC_cUFcLdi4Iduco9sVfTyZKU-agwiBigCorw=.6bd364c7-d291-47ee-9b5a-73c508d57f62@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <MPVHAegC_cUFcLdi4Iduco9sVfTyZKU-agwiBigCorw=.6bd364c7-d291-47ee-9b5a-73c508d57f62@github.com>
Message-ID: <cHHJz921uzWhomTkg-ny_pMi4Xit8Fp4zTchV9WLAk4=.83abaaa1-af68-43f4-855b-7a61860b520f@github.com>

On Tue, 14 Jan 2025 21:23:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
>> 
>> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
>> 
>> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.
>
> 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 37 additional commits since the last revision:
> 
>  - Call out the non-java threads we are most concerned with in the comment
>  - Merge tag 'jdk-25+5' into remove-init-update-refs-safepoint
>    
>    Added tag jdk-25+5 for changeset 2e00816a
>  - Encapsulate and document a method for making concurrent gc_state changes
>  - Control thread doesn't need a gc lab, also make gclabs for safepoint workers parsable
>  - Improve comments and method names
>  - Improve comments
>  - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
>  - Fix comments
>  - Fix comment, revert unnecessary change
>  - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/0e390417...ab808a11

Re-approving. I'll look through some of the wrinkles here a bit more, separately. Thanks for your explanation and the expanded documentation, which are very useful.

?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22688#pullrequestreview-2553188644

From coleenp at openjdk.org  Wed Jan 15 17:15:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 17:15:46 GMT
Subject: RFR: 8347727: Replace SIZE_FORMAT in shared gc
In-Reply-To: <gA2TqPUv-8zLslulI25W-1kjUTjN-O_QgKzdpoQPEas=.1b6ead58-719c-4f91-9911-01cfb2a3ea93@github.com>
References: <gA2TqPUv-8zLslulI25W-1kjUTjN-O_QgKzdpoQPEas=.1b6ead58-719c-4f91-9911-01cfb2a3ea93@github.com>
Message-ID: <rSUF2ZXMeemg61KwWwbMAMIxm8dkosp_bkBNRGE89rs=.187bf2a7-63d1-4e8d-8e49-dbb39328daaf@github.com>

On Tue, 14 Jan 2025 17:11:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the shared gc directory.  Most replacements were done with a script but I had a hand-edit in TaskQueueStats.
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

Thanks for reviewing Thomas, Kim and David.

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

PR Comment: https://git.openjdk.org/jdk/pull/23111#issuecomment-2593492113

From coleenp at openjdk.org  Wed Jan 15 17:15:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 17:15:46 GMT
Subject: Integrated: 8347727: Replace SIZE_FORMAT in shared gc
In-Reply-To: <gA2TqPUv-8zLslulI25W-1kjUTjN-O_QgKzdpoQPEas=.1b6ead58-719c-4f91-9911-01cfb2a3ea93@github.com>
References: <gA2TqPUv-8zLslulI25W-1kjUTjN-O_QgKzdpoQPEas=.1b6ead58-719c-4f91-9911-01cfb2a3ea93@github.com>
Message-ID: <zjeJW5dZ4bgIQJNFJcKSeYc5aGNgSvBGhJKKrLTtKFo=.bed36e5f-d6ca-454f-b998-cf8367b6dd9a@github.com>

On Tue, 14 Jan 2025 17:11:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the shared gc directory.  Most replacements were done with a script but I had a hand-edit in TaskQueueStats.
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

This pull request has now been integrated.

Changeset: 983e24fd
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/983e24fd262b5aa793a249cad39270956e1f8fc4
Stats:     110 lines in 21 files changed: 0 ins; 1 del; 109 mod

8347727: Replace SIZE_FORMAT in shared gc

Reviewed-by: kbarrett, dholmes, tschatzl

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

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

From coleenp at openjdk.org  Wed Jan 15 17:20:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 17:20:36 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
Message-ID: <PvsRC0a12UBBEVtavnUzxVGbRCQJeOYjL-_GUXcBllg=.688c3253-9037-4156-8245-408a7517f55b@github.com>

On Wed, 15 Jan 2025 13:24:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
>> Tested with building shenandoah and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge.

This should just add the label so I get the email.

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

PR Comment: https://git.openjdk.org/jdk/pull/23134#issuecomment-2593518275

From wkemper at openjdk.org  Wed Jan 15 17:45:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Jan 2025 17:45:40 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
Message-ID: <Kz8clmOqtH6-uFfuJ0Ea3ZvYAKOEKFjK5cn_KRPRXY8=.4110f78c-8e5d-4aa8-9147-1b122e6e0e39@github.com>

On Wed, 15 Jan 2025 13:24:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
>> Tested with building shenandoah and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge.

`shFreeSet.cpp` changes look good to me. Thank you!

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23134#pullrequestreview-2553491083

From wkemper at openjdk.org  Wed Jan 15 17:52:46 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Jan 2025 17:52:46 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
 [v5]
In-Reply-To: <MPVHAegC_cUFcLdi4Iduco9sVfTyZKU-agwiBigCorw=.6bd364c7-d291-47ee-9b5a-73c508d57f62@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
 <MPVHAegC_cUFcLdi4Iduco9sVfTyZKU-agwiBigCorw=.6bd364c7-d291-47ee-9b5a-73c508d57f62@github.com>
Message-ID: <Sy39Xh8K0RhKL6qi28KpPsJcHABFFLZcu76exo7ftIo=.839e0b35-6b6f-4f29-822e-ca715d69b403@github.com>

On Tue, 14 Jan 2025 21:23:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
>> 
>> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
>> 
>> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.
>
> 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 37 additional commits since the last revision:
> 
>  - Call out the non-java threads we are most concerned with in the comment
>  - Merge tag 'jdk-25+5' into remove-init-update-refs-safepoint
>    
>    Added tag jdk-25+5 for changeset 2e00816a
>  - Encapsulate and document a method for making concurrent gc_state changes
>  - Control thread doesn't need a gc lab, also make gclabs for safepoint workers parsable
>  - Improve comments and method names
>  - Improve comments
>  - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
>  - Fix comments
>  - Fix comment, revert unnecessary change
>  - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/362f847b...ab808a11

Thank you @ysramakrishna !

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

PR Comment: https://git.openjdk.org/jdk/pull/22688#issuecomment-2593579252

From wkemper at openjdk.org  Wed Jan 15 17:52:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Jan 2025 17:52:47 GMT
Subject: Integrated: 8344049: Shenandoah: Eliminate init-update-refs safepoint
In-Reply-To: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
References: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>
Message-ID: <R63kR0geIu7KoHr6WgfOoJiyD1ndiC-f_iFPvYtet1w=.4636a967-8a57-486e-a0c7-75e617faafae@github.com>

On Wed, 11 Dec 2024 19:08:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
> 
> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
> 
> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.

This pull request has now been integrated.

Changeset: 764d70b7
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/764d70b7df18e288582e616c62b0d7078f1ff3aa
Stats:     263 lines in 11 files changed: 147 ins; 70 del; 46 mod

8344049: Shenandoah: Eliminate init-update-refs safepoint
8344050: Shenandoah: Retire GC LABs concurrently
8344055: Shenandoah: Make all threads use local gc state

Reviewed-by: ysr, kdnilsen

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

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

From coleenp at openjdk.org  Wed Jan 15 18:14:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 18:14:35 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
Message-ID: <s-_Ph3SBK21NThqECCgqw7Bh3KKBTGmsbrbaOYj-RFY=.76b117d6-a0b7-4daa-a6c9-0dea5e110347@github.com>

On Wed, 15 Jan 2025 13:24:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
>> Tested with building shenandoah and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge.

Thank you for reviewing, William.  Does shenandoah have a 2 review/24 hour requirement?

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

PR Comment: https://git.openjdk.org/jdk/pull/23134#issuecomment-2593634007

From wkemper at openjdk.org  Wed Jan 15 18:20:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Jan 2025 18:20:36 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
Message-ID: <Tg6AyEMvdCX8UHxzCh-c9w5geaoLzMisAACIqdNucGU=.c9ad8574-3ba7-4443-8020-4891d6d08e59@github.com>

On Wed, 15 Jan 2025 13:24:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
>> Tested with building shenandoah and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge.

No, but I'm not a "reviewer", so my review doesn't count. I'll poke @ysramakrishna .

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

PR Comment: https://git.openjdk.org/jdk/pull/23134#issuecomment-2593644030

From stefank at openjdk.org  Wed Jan 15 18:25:41 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 15 Jan 2025 18:25:41 GMT
Subject: RFR: 8347731: Replace SIZE_FORMAT in zgc
In-Reply-To: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
References: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
Message-ID: <GKo8WAUFAxbT0nit-e3McaM_XhlTw7vJaXalYfvr6Ss=.d9d96262-1ade-4fb6-a637-f36babc933f6@github.com>

On Wed, 15 Jan 2025 12:54:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the zgc directory. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  There's a %zx in this change which I carefully made 0x%zx rather than %#zx.
> Tested with tier1-4 with the other GC changes.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23133#pullrequestreview-2553586778

From xpeng at openjdk.org  Wed Jan 15 18:37:05 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 15 Jan 2025 18:37:05 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v7]
In-Reply-To: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
Message-ID: <5buMfifBIF4gKF65pKF3r6KJW-AkYP0oxkFOqeFs6nc=.8c06e556-ae5e-46fd-aa00-c62f9823f298@github.com>

> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
> 
> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
> 
> GenShen:
> Before:
> 
> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
> 
> 
> After:
> 
> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
> 
> 
> Shenandoah:
> Before:
> 
> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
> 
> After:
> 
> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
> 
> 
> Additional changes:
> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
> * Clean up FullGC code, remove duplicate code.
> 
> Additional tests:
> - [x] CONF=macosx-aarch64-server-fastdebug make test T...

Xiaolong Peng 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 23 additional commits since the last revision:

 - Merge branch 'openjdk:master' into reset-bitmap
 - Merge branch 'openjdk:master' into reset-bitmap
 - Merge branch 'openjdk:master' into reset-bitmap
 - Adding condition "!_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress()" back and address some PR comments
 - Remove entry_reset_after_collect from ShenandoahOldGC
 - Remove condition check !_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress() from op_reset_after_collect
 - Merge branch 'openjdk:master' into reset-bitmap
 - Address review comments
 - Merge branch 'openjdk:master' into reset-bitmap
 - Remove ShenandoahResetUpdateRegionStateClosure
 - ... and 13 more: https://git.openjdk.org/jdk/compare/7bf7a567...92c63159

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22778/files
  - new: https://git.openjdk.org/jdk/pull/22778/files/9e7f342d..92c63159

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

  Stats: 6934 lines in 271 files changed: 3951 ins; 1283 del; 1700 mod
  Patch: https://git.openjdk.org/jdk/pull/22778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22778/head:pull/22778

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

From ysr at openjdk.org  Wed Jan 15 19:23:38 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 15 Jan 2025 19:23:38 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <s-_Ph3SBK21NThqECCgqw7Bh3KKBTGmsbrbaOYj-RFY=.76b117d6-a0b7-4daa-a6c9-0dea5e110347@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
 <s-_Ph3SBK21NThqECCgqw7Bh3KKBTGmsbrbaOYj-RFY=.76b117d6-a0b7-4daa-a6c9-0dea5e110347@github.com>
Message-ID: <867u2TZECkR8IdaMiAbdPHAY9kAQtVTwNfRCo4Vh35A=.088c65c6-0698-45bc-967e-e291512100c8@github.com>

On Wed, 15 Jan 2025 18:12:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix merge.
>
> Thank you for reviewing, William.  Does shenandoah have a 2 review/24 hour requirement?

Somewhat naiive question @coleenp : Why not just modify the `SIZE_FORMAT` and related definitions to use `z`, and leave all uses in hotspot code unchanged?

May be the answer is in one of the parent tickets?

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

PR Comment: https://git.openjdk.org/jdk/pull/23134#issuecomment-2593756224

From coleenp at openjdk.org  Wed Jan 15 21:35:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 21:35:42 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
Message-ID: <YBxBaX2NVqbFSCpqxh37bwzWtFCBgd-qFsqyd7NElXE=.403675be-c463-44fc-8b59-c034a351ee7e@github.com>

On Wed, 15 Jan 2025 13:24:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
>> Tested with building shenandoah and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge.

The strings are nicer with "pre string %zu all the rest of the things", rather than "pre string " SIZE_FORMAT " all the rest of the things".  i.e. nicer to not have these macros that aren't necessary.

Don't you think they look nicer?

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

PR Comment: https://git.openjdk.org/jdk/pull/23134#issuecomment-2593979980

From ysr at openjdk.org  Thu Jan 16 00:45:47 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 16 Jan 2025 00:45:47 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <YBxBaX2NVqbFSCpqxh37bwzWtFCBgd-qFsqyd7NElXE=.403675be-c463-44fc-8b59-c034a351ee7e@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
 <YBxBaX2NVqbFSCpqxh37bwzWtFCBgd-qFsqyd7NElXE=.403675be-c463-44fc-8b59-c034a351ee7e@github.com>
Message-ID: <-8ScYEYorr60KIccNlkkdGF_QIjS8gb7H6k3ZdFChcc=.dd53eff0-ba02-4a13-b8ac-f9fce825ce8c@github.com>

On Wed, 15 Jan 2025 21:32:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The strings are nicer with "pre string %zu all the rest of the things", rather than "pre string " SIZE_FORMAT " all the rest of the things". i.e. nicer to not have these macros that aren't necessary.
> 
> Don't you think they look nicer?

Yes, having to do the quote alternation is a pain, and %zu is indeed terser than SIZE_FORMAT, all right :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/23134#issuecomment-2594221414

From ysr at openjdk.org  Thu Jan 16 00:55:38 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 16 Jan 2025 00:55:38 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
Message-ID: <0GhHv5ojGjQC9y6YbPfNkZ-nhCWpMf6_A2ji8YpL6NM=.785c3e4c-ab99-4ce5-bd87-0718b8b626f4@github.com>

On Wed, 15 Jan 2025 13:24:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
>> Tested with building shenandoah and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge.

That's a ton of changes. Thank you so much for taking the time to fix these (hopefully via a script).

?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 4:

> 2:  * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved.
> 3:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
> 4:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Is it normal to update copyright header for changes such as this, i.e. for small cosmetic changes too? (In the past we got somewhat different feedback on this.)

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23134#pullrequestreview-2554424763
PR Review Comment: https://git.openjdk.org/jdk/pull/23134#discussion_r1917515102

From tschatzl at openjdk.org  Thu Jan 16 09:14:36 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 16 Jan 2025 09:14:36 GMT
Subject: RFR: 8347731: Replace SIZE_FORMAT in zgc
In-Reply-To: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
References: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
Message-ID: <YBtLxBlKRQZQPC8lY15mnhgGrW48Q9mT6uatUmsvup0=.e3a4b0fc-736f-4435-b63f-61829dd99fdc@github.com>

On Wed, 15 Jan 2025 12:54:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the zgc directory. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  There's a %zx in this change which I carefully made 0x%zx rather than %#zx.
> Tested with tier1-4 with the other GC changes.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23133#pullrequestreview-2555295054

From stefank at openjdk.org  Thu Jan 16 10:14:36 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 16 Jan 2025 10:14:36 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <sE1FRHSWW7iVRm15iO3cJHbf6gkDf9HFY9oe5oSDtlk=.4f1fef79-b0b4-4188-8cd5-080fa9702d30@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

Thanks for the reviews!

Shenandoah devs, what should I do about the comment I added in shenandoahHeap.cpp? Do you want to handle that in this patch, should I leave the comment, or should I remove it?

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

PR Comment: https://git.openjdk.org/jdk/pull/22825#issuecomment-2595108090

From jsikstro at openjdk.org  Thu Jan 16 12:25:36 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 16 Jan 2025 12:25:36 GMT
Subject: RFR: 8347731: Replace SIZE_FORMAT in zgc
In-Reply-To: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
References: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
Message-ID: <6-p29V8arl5xvTjCmrsyPgacc6TKIhjuprOLYu454qE=.8beac7d2-2333-48ec-b988-360551273e4b@github.com>

On Wed, 15 Jan 2025 12:54:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the zgc directory. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  There's a %zx in this change which I carefully made 0x%zx rather than %#zx.
> Tested with tier1-4 with the other GC changes.

Marked as reviewed by jsikstro (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23133#pullrequestreview-2555814563

From coleenp at openjdk.org  Thu Jan 16 12:50:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 12:50:48 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
Message-ID: <DA-U7woITsU891i3bBVsiUu-rB9VRGxxFmUechrpIzE=.8dc31982-2b01-4f53-b9a3-4630acbd8ae1@github.com>

On Wed, 15 Jan 2025 13:24:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
>> Tested with building shenandoah and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge.

Thanks William and Ramki!

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

PR Comment: https://git.openjdk.org/jdk/pull/23134#issuecomment-2595520453

From coleenp at openjdk.org  Thu Jan 16 12:50:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 12:50:53 GMT
Subject: Integrated: 8347732: Replace SIZE_FORMAT in shenandoah
In-Reply-To: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
Message-ID: <EKTuddn7tBgTf8xNwiH9X8tK_6MNiraGOeDCtyHw2n4=.b60882c2-8e93-4e81-845c-f575aa7dffd4@github.com>

On Wed, 15 Jan 2025 13:03:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the shenandoah directories.  The goal is for one of these changes to remove SIZE_FORMAT so this change is necessary.  Most was done with a script, except the SIZE_FORMAT_W(10) in print_gc_stats which was changed manually to retain the formatting.
> Tested with building shenandoah and tier1-4.

This pull request has now been integrated.

Changeset: cbe2f965
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbe2f9654eb7330c2e8cbe74e8abc2db63ec867b
Stats:     337 lines in 45 files changed: 40 ins; 0 del; 297 mod

8347732: Replace SIZE_FORMAT in shenandoah

Reviewed-by: wkemper, ysr

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

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

From coleenp at openjdk.org  Thu Jan 16 12:50:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 12:50:51 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <0GhHv5ojGjQC9y6YbPfNkZ-nhCWpMf6_A2ji8YpL6NM=.785c3e4c-ab99-4ce5-bd87-0718b8b626f4@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
 <0GhHv5ojGjQC9y6YbPfNkZ-nhCWpMf6_A2ji8YpL6NM=.785c3e4c-ab99-4ce5-bd87-0718b8b626f4@github.com>
Message-ID: <Rpt3y5RyzLXn6uUd5GWjjSKMhXO5sgXWqFGxwLPzWy4=.4a9222b0-70b3-479f-9afd-af55f9329ca8@github.com>

On Thu, 16 Jan 2025 00:43:47 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix merge.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 4:
> 
>> 2:  * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved.
>> 3:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
>> 4:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Is it normal to update copyright header for changes such as this, i.e. for small cosmetic changes too? (In the past we got somewhat different feedback on this.)

I asked and I was told to add the copyright. ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23134#discussion_r1918436424

From coleenp at openjdk.org  Thu Jan 16 12:52:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 12:52:44 GMT
Subject: RFR: 8347731: Replace SIZE_FORMAT in zgc
In-Reply-To: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
References: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
Message-ID: <ZspYKiwmvlPhlGfsxcTuquLzJcnM1naN-nWmvk6o2do=.78dddeef-e546-40a2-9187-a6e3550c5480@github.com>

On Wed, 15 Jan 2025 12:54:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the zgc directory. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  There's a %zx in this change which I carefully made 0x%zx rather than %#zx.
> Tested with tier1-4 with the other GC changes.

Thanks Stefan, Thomas and Joel for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/23133#issuecomment-2595528241

From coleenp at openjdk.org  Thu Jan 16 12:52:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 12:52:44 GMT
Subject: Integrated: 8347731: Replace SIZE_FORMAT in zgc
In-Reply-To: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
References: <b36RqCz27CyXeVB154oL1gcK4RrBVWt0x5USEhYPGOc=.d229cd93-8fdb-4505-a5ea-214654e38ef6@github.com>
Message-ID: <-6d7t183peawNF2S5wXCQ0lDonwPcnjw7wYcN7JvegM=.4fea2580-0937-4abc-b147-636d54516e5a@github.com>

On Wed, 15 Jan 2025 12:54:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the zgc directory. The only hand edit that I did for this one was SIZE_FORMAT_W(7) because my sed script had problems with it.  There's a %zx in this change which I carefully made 0x%zx rather than %#zx.
> Tested with tier1-4 with the other GC changes.

This pull request has now been integrated.

Changeset: 8bfa5405
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8bfa54055013ca92696982c86ed3869627718219
Stats:     79 lines in 19 files changed: 0 ins; 0 del; 79 mod

8347731: Replace SIZE_FORMAT in zgc

Reviewed-by: stefank, tschatzl, jsikstro

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

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

From ayang at openjdk.org  Thu Jan 16 13:42:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 16 Jan 2025 13:42:14 GMT
Subject: RFR: 8347923: Parallel: Simplify
 compute_survivor_space_size_and_threshold
Message-ID: <rPj1Wvx-tNWIDeNhw0M3-yJqMYq_V0Z8XTVN9G_uK0c=.d87527bd-2379-4b53-9e06-4dcd5f7ec89f@github.com>

Trivial extracting out the common subexpression from both if-else branches.

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

Commit messages:
 - trivial

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

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

From kbarrett at openjdk.org  Thu Jan 16 14:25:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 16 Jan 2025 14:25:45 GMT
Subject: RFR: 8347730: Replace SIZE_FORMAT in g1
In-Reply-To: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
References: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
Message-ID: <zlvZ1fpRkSs0ezI_x3ZScgPmuVwtKK65vRNPjbwUNFo=.8f15a125-e028-4962-b193-9239eb2843f5@github.com>

On Tue, 14 Jan 2025 18:40:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the g1 directory.  Most edits were by script but SIZE_FORMAT_W(n) was done sort of by hand.  Also fixed one place where preexisting formatting was bad.
> 
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1MonitoringSupport.cpp line 293:

> 291:   // _old_gen_committed is calculated in terms of _old_gen_used value.
> 292:   assert(_old_gen_used <= _old_gen_committed, "Old gen used bytes(%zu"
> 293:          ") should be less than or equal to old gen committed(%zu)",

Move the first close paren to the previous line in these two changes.

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

PR Review: https://git.openjdk.org/jdk/pull/23114#pullrequestreview-2556296168
PR Review Comment: https://git.openjdk.org/jdk/pull/23114#discussion_r1918638293

From coleenp at openjdk.org  Thu Jan 16 14:25:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 14:25:45 GMT
Subject: RFR: 8347730: Replace SIZE_FORMAT in g1
In-Reply-To: <zlvZ1fpRkSs0ezI_x3ZScgPmuVwtKK65vRNPjbwUNFo=.8f15a125-e028-4962-b193-9239eb2843f5@github.com>
References: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
 <zlvZ1fpRkSs0ezI_x3ZScgPmuVwtKK65vRNPjbwUNFo=.8f15a125-e028-4962-b193-9239eb2843f5@github.com>
Message-ID: <q5c5aU0tqScKe5RypRV6Ddvc3g3V6Dm-X0gV0feFwxE=.71bcb579-5f20-41b3-bfa6-5cf00576aed6@github.com>

On Thu, 16 Jan 2025 14:16:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the g1 directory.  Most edits were by script but SIZE_FORMAT_W(n) was done sort of by hand.  Also fixed one place where preexisting formatting was bad.
>> 
>> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.
>
> src/hotspot/share/gc/g1/g1MonitoringSupport.cpp line 293:
> 
>> 291:   // _old_gen_committed is calculated in terms of _old_gen_used value.
>> 292:   assert(_old_gen_used <= _old_gen_committed, "Old gen used bytes(%zu"
>> 293:          ") should be less than or equal to old gen committed(%zu)",
> 
> Move the first close paren to the previous line in these two changes.

Okay, I tried to find these strange formats but missed this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23114#discussion_r1918650244

From coleenp at openjdk.org  Thu Jan 16 14:34:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 14:34:18 GMT
Subject: RFR: 8347730: Replace SIZE_FORMAT in g1 [v2]
In-Reply-To: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
References: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
Message-ID: <_chLQZrWTMW-RxfDZ3wr1y1J-j5CuTPf2hZ0XWsmKMY=.9ec5039c-aab7-4d2b-ac27-ac7e549e033d@github.com>

> Please review this change to replace SIZE_FORMAT with %zu in the g1 directory.  Most edits were by script but SIZE_FORMAT_W(n) was done sort of by hand.  Also fixed one place where preexisting formatting was bad.
> 
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix formatting - looks a lot better now.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23114/files
  - new: https://git.openjdk.org/jdk/pull/23114/files/504ca4c7..a0efd453

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

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

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

From kbarrett at openjdk.org  Thu Jan 16 14:34:18 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 16 Jan 2025 14:34:18 GMT
Subject: RFR: 8347730: Replace SIZE_FORMAT in g1 [v2]
In-Reply-To: <_chLQZrWTMW-RxfDZ3wr1y1J-j5CuTPf2hZ0XWsmKMY=.9ec5039c-aab7-4d2b-ac27-ac7e549e033d@github.com>
References: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
 <_chLQZrWTMW-RxfDZ3wr1y1J-j5CuTPf2hZ0XWsmKMY=.9ec5039c-aab7-4d2b-ac27-ac7e549e033d@github.com>
Message-ID: <V7XdWGqzt3GF307flbU3RUtpBd8Rtzv5zfbJrS7bsbs=.84ab7f27-786c-4cd5-8c00-c845302d0a78@github.com>

On Thu, 16 Jan 2025 14:31:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the g1 directory.  Most edits were by script but SIZE_FORMAT_W(n) was done sort of by hand.  Also fixed one place where preexisting formatting was bad.
>> 
>> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting - looks a lot better now.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23114#pullrequestreview-2556335142

From coleenp at openjdk.org  Thu Jan 16 14:34:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 14:34:18 GMT
Subject: Integrated: 8347730: Replace SIZE_FORMAT in g1
In-Reply-To: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
References: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
Message-ID: <GukJg0iKMS1CYOI_1mmzRp9gY7YtuWrG-50AOuEP4k8=.8b562105-7659-484f-bcc8-e44d528dc661@github.com>

On Tue, 14 Jan 2025 18:40:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the g1 directory.  Most edits were by script but SIZE_FORMAT_W(n) was done sort of by hand.  Also fixed one place where preexisting formatting was bad.
> 
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

This pull request has now been integrated.

Changeset: bfa0cb79
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfa0cb79169ab00b0b600895d7a0f4038e8b8880
Stats:     177 lines in 37 files changed: 0 ins; 0 del; 177 mod

8347730: Replace SIZE_FORMAT in g1

Reviewed-by: kbarrett, tschatzl

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

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

From coleenp at openjdk.org  Thu Jan 16 14:34:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 14:34:18 GMT
Subject: RFR: 8347730: Replace SIZE_FORMAT in g1
In-Reply-To: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
References: <o4p47wHFVPUZRiIYmomaBll60rKAiaY_mtraEeMxzQU=.d6e72577-59f6-4927-b9b8-66a3a45f1da9@github.com>
Message-ID: <7raKmkT9mVozGDgpcW9KOAbM4pS1E1brCLT1NT0YwjQ=.441781fc-3540-4b8e-95ff-f55d4779286c@github.com>

On Tue, 14 Jan 2025 18:40:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the g1 directory.  Most edits were by script but SIZE_FORMAT_W(n) was done sort of by hand.  Also fixed one place where preexisting formatting was bad.
> 
> Tested all the GC changes together (other PRs coming) with tier1-4 on x86 and aarch64.

Thanks Thomas and Kim.

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

PR Comment: https://git.openjdk.org/jdk/pull/23114#issuecomment-2595881172

From ysr at openjdk.org  Thu Jan 16 15:46:53 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 16 Jan 2025 15:46:53 GMT
Subject: RFR: 8347732: Replace SIZE_FORMAT in shenandoah [v3]
In-Reply-To: <Rpt3y5RyzLXn6uUd5GWjjSKMhXO5sgXWqFGxwLPzWy4=.4a9222b0-70b3-479f-9afd-af55f9329ca8@github.com>
References: <CXhIK9tNmZsOeJvBDrb-Q17iUAd7alrqsAxqLFeB440=.ad30ad20-0264-4185-9c6b-55398f2e9fbf@github.com>
 <4JkLz7a8lRcfgunWw7S9stS5xZ2r9UiV9o6cuCROJBE=.72e5d262-d391-4559-bf04-d8d2f1638606@github.com>
 <0GhHv5ojGjQC9y6YbPfNkZ-nhCWpMf6_A2ji8YpL6NM=.785c3e4c-ab99-4ce5-bd87-0718b8b626f4@github.com>
 <Rpt3y5RyzLXn6uUd5GWjjSKMhXO5sgXWqFGxwLPzWy4=.4a9222b0-70b3-479f-9afd-af55f9329ca8@github.com>
Message-ID: <P4R2Wr5iIC8iM4EaYsTqeJXNetDo90uDu2XYD1i9J1g=.f1d17518-1afe-40a7-a659-0ae57e3319e6@github.com>

On Thu, 16 Jan 2025 12:43:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 4:
>> 
>>> 2:  * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved.
>>> 3:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
>>> 4:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
>> 
>> Is it normal to update copyright header for changes such as this, i.e. for small cosmetic changes too? (In the past we got somewhat different feedback on this.)
>
> I asked and I was told to add the copyright. ?

OK, thanks for checking, Coleen!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23134#discussion_r1918784451

From tschatzl at openjdk.org  Thu Jan 16 15:53:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 16 Jan 2025 15:53:38 GMT
Subject: RFR: 8347923: Parallel: Simplify
 compute_survivor_space_size_and_threshold
In-Reply-To: <rPj1Wvx-tNWIDeNhw0M3-yJqMYq_V0Z8XTVN9G_uK0c=.d87527bd-2379-4b53-9e06-4dcd5f7ec89f@github.com>
References: <rPj1Wvx-tNWIDeNhw0M3-yJqMYq_V0Z8XTVN9G_uK0c=.d87527bd-2379-4b53-9e06-4dcd5f7ec89f@github.com>
Message-ID: <bKKeQweyQdB9JciyfrPafR4DUsYICPCDlO9njM1Jhzg=.cac0e2dd-43fd-4836-a859-17e5178ffcc2@github.com>

On Thu, 16 Jan 2025 13:36:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial extracting out the common subexpression from both if-else branches.

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23155#pullrequestreview-2556567880

From ysr at openjdk.org  Thu Jan 16 16:44:39 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 16 Jan 2025 16:44:39 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <tdn7ABEb9_pCL9kMO3nTDeUsPb-lA9Pnhliml6_xGK8=.721a7b1f-fbd8-46dd-8015-90645d4cf7ac@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

The changes look fine to me.

We probably want to clean up Shenandoah code related to failure to reserve space in a separate ticket. Thanks for bringing these changes to our attention; I had missed the original refactoring of address range reservations that you had started before the holidays.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 391:

> 389: 
> 390:       // Maybe Shenandoah wants to check the the memory got reserved here?
> 391: 

Thanks for tagging us Stefan. There seem to be a few places where we might want to check & guard for failure to reserve the space. It might make sense to clean up these failure paths in a separate ticket. cc @earthling-amzn @shipilev ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2556672862
PR Review Comment: https://git.openjdk.org/jdk/pull/22825#discussion_r1918859248

From wkemper at openjdk.org  Thu Jan 16 17:25:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Jan 2025 17:25:38 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <tdn7ABEb9_pCL9kMO3nTDeUsPb-lA9Pnhliml6_xGK8=.721a7b1f-fbd8-46dd-8015-90645d4cf7ac@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <tdn7ABEb9_pCL9kMO3nTDeUsPb-lA9Pnhliml6_xGK8=.721a7b1f-fbd8-46dd-8015-90645d4cf7ac@github.com>
Message-ID: <m8uOP6EyKhIJ2EiHBGgHxhHaUoa5d8_m3donYky7e2Y=.6a2d946a-eb70-4c95-939d-713ecf2f23f2@github.com>

On Thu, 16 Jan 2025 16:32:02 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
>> 
>> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
>> 
>> Tested tier1 and GHA, but will run more tests when/if this gets accepted.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 391:
> 
>> 389: 
>> 390:       // Maybe Shenandoah wants to check the the memory got reserved here?
>> 391: 
> 
> Thanks for tagging us Stefan. There seem to be a few places where we might want to check & guard for failure to reserve the space. It might make sense to clean up these failure paths in a separate ticket. cc @earthling-amzn @shipilev ?

The method `ShenandoahHeap::reserve` should `vm_exit_during_initialization` if the memory isn't reserved. Between that and the collection set memory here, I believe that would cover Shenandoah's cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22825#discussion_r1918930136

From wkemper at openjdk.org  Thu Jan 16 19:47:49 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Jan 2025 19:47:49 GMT
Subject: RFR: 8347617: Shenandoah: Use consistent name for update references
 phase
Message-ID: <VvbfL7laOJH_zXaLeIisQx6MJW_JWOGgd0ubxDRqgZw=.f60bd3ac-809b-4778-a3ba-37e8a40c9a32@github.com>

During the review of https://github.com/openjdk/jdk/pull/22688, we discovered that some methods and variables used `updaterefs`, while most used `update_refs` (or `UpdateRefs`). This PR changes all of the `updaterefs` names to `update_refs` for consistency.

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

Commit messages:
 - Use consistent names for update references

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

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

From ysr at openjdk.org  Thu Jan 16 20:01:44 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 16 Jan 2025 20:01:44 GMT
Subject: RFR: 8347617: Shenandoah: Use consistent name for update
 references phase
In-Reply-To: <VvbfL7laOJH_zXaLeIisQx6MJW_JWOGgd0ubxDRqgZw=.f60bd3ac-809b-4778-a3ba-37e8a40c9a32@github.com>
References: <VvbfL7laOJH_zXaLeIisQx6MJW_JWOGgd0ubxDRqgZw=.f60bd3ac-809b-4778-a3ba-37e8a40c9a32@github.com>
Message-ID: <hukVcIuvprc733xJGabTCbX5UOthvEOHRo4pVSWGxi4=.b03e5936-e91f-4d5b-98b5-891701a5e118@github.com>

On Thu, 16 Jan 2025 19:43:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

> During the review of https://github.com/openjdk/jdk/pull/22688, we discovered that some methods and variables used `updaterefs`, while most used `update_refs` (or `UpdateRefs`). This PR changes all of the `updaterefs` names to `update_refs` for consistency.

Thanks for making these mutually consistent!

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23164#pullrequestreview-2557180908

From wkemper at openjdk.org  Thu Jan 16 21:00:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Jan 2025 21:00:36 GMT
Subject: Integrated: 8347617: Shenandoah: Use consistent name for update
 references phase
In-Reply-To: <VvbfL7laOJH_zXaLeIisQx6MJW_JWOGgd0ubxDRqgZw=.f60bd3ac-809b-4778-a3ba-37e8a40c9a32@github.com>
References: <VvbfL7laOJH_zXaLeIisQx6MJW_JWOGgd0ubxDRqgZw=.f60bd3ac-809b-4778-a3ba-37e8a40c9a32@github.com>
Message-ID: <RzA4-eNgEF0ryJb3gT9DQOIPDSKtfqtPBWRdI3kR-BA=.b2b2c6f2-4cd9-44ce-bc69-7468409d59ab@github.com>

On Thu, 16 Jan 2025 19:43:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

> During the review of https://github.com/openjdk/jdk/pull/22688, we discovered that some methods and variables used `updaterefs`, while most used `update_refs` (or `UpdateRefs`). This PR changes all of the `updaterefs` names to `update_refs` for consistency.

This pull request has now been integrated.

Changeset: 0330ca42
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0330ca4221ba7bacb0eaeed1a8cdc3d5c3653a83
Stats:     64 lines in 18 files changed: 0 ins; 0 del; 64 mod

8347617: Shenandoah: Use consistent name for update references phase

Reviewed-by: ysr

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

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

From rcastanedalo at openjdk.org  Mon Jan 20 09:45:10 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 20 Jan 2025 09:45:10 GMT
Subject: RFR: 8347563: C2: clean up ModRefBarrierSetC2
Message-ID: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>

This cleanup removes `ModRefBarrierSetC2::pre_barrier()` (which is a no-op after [JDK-8334060](https://bugs.openjdk.org/browse/JDK-8334060)) and unused arguments of `ModRefBarrierSetC2::post_barrier()`. Thanks to @TobiHartmann for reporting!

**Testing:** tier1-3.

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

Commit messages:
 - Update copyright year
 - Remove unused import
 - Remove unused arguments from ModRefBarrierSetC2::post_barrier
 - Remove unused import
 - Remove no-op function ModRefBarrierSetC2::pre_barrier

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

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

From ayang at openjdk.org  Mon Jan 20 09:54:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Jan 2025 09:54:38 GMT
Subject: RFR: 8347923: Parallel: Simplify
 compute_survivor_space_size_and_threshold
In-Reply-To: <rPj1Wvx-tNWIDeNhw0M3-yJqMYq_V0Z8XTVN9G_uK0c=.d87527bd-2379-4b53-9e06-4dcd5f7ec89f@github.com>
References: <rPj1Wvx-tNWIDeNhw0M3-yJqMYq_V0Z8XTVN9G_uK0c=.d87527bd-2379-4b53-9e06-4dcd5f7ec89f@github.com>
Message-ID: <EqR-G3dbiL3PLKsoAHLWRNDC2QsKawvH4gcZgpFZHa4=.69bf4cd0-295a-49c3-a4f7-5572adf06b7e@github.com>

On Thu, 16 Jan 2025 13:36:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial extracting out the common subexpression from both if-else branches.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23155#issuecomment-2601927610

From ayang at openjdk.org  Mon Jan 20 09:54:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Jan 2025 09:54:38 GMT
Subject: Integrated: 8347923: Parallel: Simplify
 compute_survivor_space_size_and_threshold
In-Reply-To: <rPj1Wvx-tNWIDeNhw0M3-yJqMYq_V0Z8XTVN9G_uK0c=.d87527bd-2379-4b53-9e06-4dcd5f7ec89f@github.com>
References: <rPj1Wvx-tNWIDeNhw0M3-yJqMYq_V0Z8XTVN9G_uK0c=.d87527bd-2379-4b53-9e06-4dcd5f7ec89f@github.com>
Message-ID: <C0qfzfT04qACPNEb0jVk0hE0E2mWRvZtd5N7GMDzwDo=.d2241255-a828-4c8b-9e04-25047ea47d6f@github.com>

On Thu, 16 Jan 2025 13:36:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial extracting out the common subexpression from both if-else branches.

This pull request has now been integrated.

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

8347923: Parallel: Simplify compute_survivor_space_size_and_threshold

Reviewed-by: tschatzl

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

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

From ayang at openjdk.org  Mon Jan 20 10:19:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Jan 2025 10:19:38 GMT
Subject: RFR: 8347563: C2: clean up ModRefBarrierSetC2
In-Reply-To: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
References: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
Message-ID: <0uTrUfGM0OLh42B_zf2XNg1GuudzDPqxh4oTHSaaSgQ=.21acab24-15c7-492d-891d-85b93f9a5296@github.com>

On Tue, 14 Jan 2025 17:47:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup removes `ModRefBarrierSetC2::pre_barrier()` (which is a no-op after [JDK-8334060](https://bugs.openjdk.org/browse/JDK-8334060)) and unused arguments of `ModRefBarrierSetC2::post_barrier()`. Thanks to @TobiHartmann for reporting!
> 
> **Testing:** tier1-3.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23112#pullrequestreview-2561956880

From ayang at openjdk.org  Mon Jan 20 10:22:08 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Jan 2025 10:22:08 GMT
Subject: RFR: 8348089: Serial: Remove virtual specifier in SerialHeap
Message-ID: <GU-XVCk_xq0sfNXbDwlk0E0dorj74su1CdJFPe0zfAk=.430f8ba1-6586-42ab-a3e4-13636660ba5e@github.com>

Trivial removing unused `virtual` specifier and move `protected` methods to `private`.

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

Commit messages:
 - virtual

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

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

From rcastanedalo at openjdk.org  Mon Jan 20 10:35:40 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 20 Jan 2025 10:35:40 GMT
Subject: RFR: 8347563: C2: clean up ModRefBarrierSetC2
In-Reply-To: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
References: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
Message-ID: <GbfZ3XqwZrEAIanfIc3-xvzysAmq7TGyY0htqQz8Dxk=.3b05223e-8b2c-466d-b07a-7c2c8c1d7778@github.com>

On Tue, 14 Jan 2025 17:47:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup removes `ModRefBarrierSetC2::pre_barrier()` (which is a no-op after [JDK-8334060](https://bugs.openjdk.org/browse/JDK-8334060)) and unused arguments of `ModRefBarrierSetC2::post_barrier()`. Thanks to @TobiHartmann for reporting!
> 
> **Testing:** tier1-3.

Thanks for reviewing, Albert!

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

PR Comment: https://git.openjdk.org/jdk/pull/23112#issuecomment-2602040329

From tschatzl at openjdk.org  Mon Jan 20 11:44:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 20 Jan 2025 11:44:35 GMT
Subject: RFR: 8347563: C2: clean up ModRefBarrierSetC2
In-Reply-To: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
References: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
Message-ID: <wveFkar0KLOZNyu7TV5QtiXwJIooH1tbcq1yJM_l4WY=.fade323c-3577-4b76-b100-7f0d9342d250@github.com>

On Tue, 14 Jan 2025 17:47:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup removes `ModRefBarrierSetC2::pre_barrier()` (which is a no-op after [JDK-8334060](https://bugs.openjdk.org/browse/JDK-8334060)) and unused arguments of `ModRefBarrierSetC2::post_barrier()`. Thanks to @TobiHartmann for reporting!
> 
> **Testing:** tier1-3.

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23112#pullrequestreview-2562166129

From stefank at openjdk.org  Mon Jan 20 12:39:35 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 20 Jan 2025 12:39:35 GMT
Subject: RFR: 8348089: Serial: Remove virtual specifier in SerialHeap
In-Reply-To: <GU-XVCk_xq0sfNXbDwlk0E0dorj74su1CdJFPe0zfAk=.430f8ba1-6586-42ab-a3e4-13636660ba5e@github.com>
References: <GU-XVCk_xq0sfNXbDwlk0E0dorj74su1CdJFPe0zfAk=.430f8ba1-6586-42ab-a3e4-13636660ba5e@github.com>
Message-ID: <rYDjchhagrEp4WLJ_28KQ1jThF5NH0WNqqp5_lUqgPs=.8761d783-f8c5-4f20-b2a9-9da5255c1f91@github.com>

On Mon, 20 Jan 2025 10:16:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unused `virtual` specifier and move `protected` methods to `private`.

Looks good, but should the `full` parameter be removed now that it isn't used?

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23196#pullrequestreview-2562284439

From ayang at openjdk.org  Mon Jan 20 12:49:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Jan 2025 12:49:38 GMT
Subject: RFR: 8348089: Serial: Remove virtual specifier in SerialHeap
In-Reply-To: <rYDjchhagrEp4WLJ_28KQ1jThF5NH0WNqqp5_lUqgPs=.8761d783-f8c5-4f20-b2a9-9da5255c1f91@github.com>
References: <GU-XVCk_xq0sfNXbDwlk0E0dorj74su1CdJFPe0zfAk=.430f8ba1-6586-42ab-a3e4-13636660ba5e@github.com>
 <rYDjchhagrEp4WLJ_28KQ1jThF5NH0WNqqp5_lUqgPs=.8761d783-f8c5-4f20-b2a9-9da5255c1f91@github.com>
Message-ID: <desuU_-KTxWjVIkFQreU48QHUQLk9UQMLqLhr_clcfc=.52fea27f-b809-43dc-8116-fdf185ae58d9@github.com>

On Mon, 20 Jan 2025 12:36:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> should the full parameter be removed now that it isn't used?

Yes, tracked by https://bugs.openjdk.org/browse/JDK-8331723

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23196#issuecomment-2602332667

From ayang at openjdk.org  Mon Jan 20 12:49:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Jan 2025 12:49:38 GMT
Subject: Integrated: 8348089: Serial: Remove virtual specifier in SerialHeap
In-Reply-To: <GU-XVCk_xq0sfNXbDwlk0E0dorj74su1CdJFPe0zfAk=.430f8ba1-6586-42ab-a3e4-13636660ba5e@github.com>
References: <GU-XVCk_xq0sfNXbDwlk0E0dorj74su1CdJFPe0zfAk=.430f8ba1-6586-42ab-a3e4-13636660ba5e@github.com>
Message-ID: <T6fQXy6I1BBV2xR3TmjkRbQxvn_o6tLPcQb5FdPWoDY=.98f750b1-21e0-44d8-a708-0b5baa222dd4@github.com>

On Mon, 20 Jan 2025 10:16:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unused `virtual` specifier and move `protected` methods to `private`.

This pull request has now been integrated.

Changeset: 3c923926
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c9239263f89ad505c19f27626e824740079712a
Stats:     7 lines in 1 file changed: 3 ins; 4 del; 0 mod

8348089: Serial: Remove virtual specifier in SerialHeap

Reviewed-by: stefank

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

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

From rcastanedalo at openjdk.org  Mon Jan 20 13:06:35 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 20 Jan 2025 13:06:35 GMT
Subject: RFR: 8347563: C2: clean up ModRefBarrierSetC2
In-Reply-To: <wveFkar0KLOZNyu7TV5QtiXwJIooH1tbcq1yJM_l4WY=.fade323c-3577-4b76-b100-7f0d9342d250@github.com>
References: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
 <wveFkar0KLOZNyu7TV5QtiXwJIooH1tbcq1yJM_l4WY=.fade323c-3577-4b76-b100-7f0d9342d250@github.com>
Message-ID: <-RizI7-peRpjTTHyiH0dLXjI0pjknPhbqL8m-x-tKH8=.5a352f2e-7fa2-465a-8fa9-7b685ddf81a1@github.com>

On Mon, 20 Jan 2025 11:41:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> lgtm.

Thanks, Thomas!

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

PR Comment: https://git.openjdk.org/jdk/pull/23112#issuecomment-2602378091

From ayang at openjdk.org  Mon Jan 20 13:27:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Jan 2025 13:27:45 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v4]
In-Reply-To: <QVPozXe1wyqYAfNRsXstws1NN8JCML5iBuDP4styP1E=.680fec3f-976d-4364-9db8-72d1e09fa756@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
 <QVPozXe1wyqYAfNRsXstws1NN8JCML5iBuDP4styP1E=.680fec3f-976d-4364-9db8-72d1e09fa756@github.com>
Message-ID: <cgnlUh4h5hTkx3cqMHOdhJk7_PtPeWTGFl-csz3E6JE=.0b8c5cdd-502f-4c80-9ec6-b47d587785bc@github.com>

On Fri, 3 Jan 2025 21:48:47 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
>> 
>> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.
>
> Zhengyu Gu 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:
> 
>  - Adopt latest PartialArrayStats changes
>  - Merge branch 'master' into JDK-8339668
>  - Merge branch 'master' into JDK-8339668
>  - @tschatzl's ScannerTask changes
>  - @tschatzl's comment
>  - v8
>  - v7
>  - v6
>  - v5
>  - v4
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/e753605f...0ed1a358

Could you also sync the PR with master?

src/hotspot/share/gc/parallel/psCompactionManager.cpp line 62:

> 60: ParCompactionManager::ParCompactionManager(PreservedMarks* preserved_marks,
> 61:                                            ReferenceProcessor* ref_processor)
> 62:   :_partial_array_splitter(_partial_array_state_manager, ParallelGCThreads),

I feel it's best to avoid using `ParallelGCThreads` directly; instead, pass in `parallel_gc_threads` in `new ParCompactionManager` below. WDYT?

src/hotspot/share/gc/parallel/psCompactionManager.cpp line 131:

> 129:     // The destination array is unused when processing states.
> 130:     _partial_array_splitter.start(&_marking_stack, obj_array, nullptr, array_length);
> 131:   int end = checked_cast<int>(initial_chunk_size);

I wonder if we can change the callee so that we don't need `checked_cast` here. (Intuitively, [start, end) denotes a range and both number should never be negative.)

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

PR Review: https://git.openjdk.org/jdk/pull/21089#pullrequestreview-2562355266
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1922381325
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1922400625

From tschatzl at openjdk.org  Mon Jan 20 14:57:37 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 20 Jan 2025 14:57:37 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC [v2]
In-Reply-To: <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
 <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>
Message-ID: <wW_GwuTWNhO2bT8yoOdi83U4sG4RVBa8FsLJwJT3L7c=.b9df3624-35cd-469b-a8c3-b491e9ff4d60@github.com>

On Mon, 6 Jan 2025 14:36:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR introduces a new strategy to determine whether an allocation should be attempted in the old generation or if a GC cycle should be initiated, based on the `GCTimeRatio`. With this change, the benchmark attached to the ticket now completes in ~13 GC, a significant improvement compared to the >1000 GC observed previously.
>> 
>> 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 s1-gc-time-ratio
>  - s1-gc-time-ratio

As far as I understand, the test program expands that `ArrayList` with new `Short` objects, allocating until OOM.

The problem to be solved in this case is how quickly the collector goes OOM; it also is related to the C2 compiler doing reallocation of C2 stack-allocated objects (when I ran the test with `-XX:TieredStopAtLevel=3` Serial GC also quickly OOMEd reproducably).

Current code, since the typical allocation here is small, prefers doing a GC pause to allocation in old gen because the allocation is small (that `Short` object). The GC pause finds out that it should do a full gc only because its predictions indicate that the young gc is "unsafe" anyway (it's not "unsafe" as in not able to do it, but likely to end up in an evacuation failure).

The reason why the application will fail faster is that it allows many more increments of that `list` array without GC. Without the change, as the that array gets larger, the frequency of the GCs will get larger without noticable more promotion going on as the amount of possible reallocations of `list` per GC gets smaller. And it will do full gcs all the time because of the predictions indicating an unsafe young gc (which is correct as the `list` array will be > to-space quickly).

(It would be nice if the title and description of the CR somehow reflected this - it reads like there is no support of direct allocation in old gen for Serial GC which is in fact not the case).

Incidentally, Parallel GC has the same issue, running hundreds of full gcs before terminating (I did not check how many it takes, and probably never also waited for Serial GC).

As far as I understand the change, this change prevents "back-to-back" GCs, opting for allocating everything into the old generation (if not full) instead. I wonder if that has not negative impact (more full gcs) for applications that legitimately allocate lots of (short-living) objects as this will fill up the old generation (much) faster than before. Particularly applications that use relatively small heap for that.
It seems like this behavior may be advantageous for startup when supposedly initializing/loading data structures too (just fill up the whole heap and compact completely).

Did you run some other benchmarks with this change? (Maybe the smaller dacapo benchmarks at "reasonably" sized heaps will show something?)

I'm actually a bit conflicted about this change. It seems to fix a (rare?) policy issue, but at the same time adds a new mechanic (use of `GCTimeRatio`) for Serial GC.
So for now I would like to wait for measurements on potential impact on "more realistic" applications.

Hth,
  Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/22899#issuecomment-2602631622

From kirk at kodewerk.com  Mon Jan 20 19:16:49 2025
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Mon, 20 Jan 2025 20:16:49 +0100
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC [v2]
In-Reply-To: <7v0-msW0bLb0qqi1dPLZeCWJH1yRkQ6Wi2tS3eNG2YQ=.12c38d9c-5de0-4f37-a7bb-df253a620f8a@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
 <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>
 <7v0-msW0bLb0qqi1dPLZeCWJH1yRkQ6Wi2tS3eNG2YQ=.12c38d9c-5de0-4f37-a7bb-df253a620f8a@github.com>
Message-ID: <048DAAFC-F223-452B-8738-8200B83BB079@kodewerk.com>

Hi,

One of the more important goals when tuning generational collectors and especially when tuning the the serial and parallel is to minimize the number of transients that end up in tenured. With that in mind I?m nervous about allocating in tenured to avoid a collection cycle. First, the probability that these (prematurely promoted) allocations are transit is likely > 90%. More over, transients in tenured tend to create zombies. Zombies put further pressure on tenure. Each of these ?conditions? will increase the frequency of full collections and fulls are way more costly than young collections.

IME, techniques that have been tried in the past to avoid collections end up being more expensive than simply triggering the collection when it is needed. Worst case, I?d allocate in the active survivor space as that should be about 50% empty by default. At least that space will be collected by the next young gen thus avoiding the problems that come with having transients in tenured.

Kind regards,
Kirk Pepperdine


> On Jan 7, 2025, at 8:08?AM, Guoxiong Li <gli at openjdk.org> wrote:
> 
> On Mon, 6 Jan 2025 14:36:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
> 
>>> This PR introduces a new strategy to determine whether an allocation should be attempted in the old generation or if a GC cycle should be initiated, based on the `GCTimeRatio`. With this change, the benchmark attached to the ticket now completes in ~13 GC, a significant improvement compared to the >1000 GC observed previously.
>>> 
>>> 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 s1-gc-time-ratio
>> - s1-gc-time-ratio
> 
> Looks good.
> 
> -------------
> 
> Marked as reviewed by gli (Reviewer).
> 
> PR Review: https://git.openjdk.org/jdk/pull/22899#pullrequestreview-2533524913


From ayang at openjdk.org  Mon Jan 20 20:05:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Jan 2025 20:05:35 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC [v2]
In-Reply-To: <wW_GwuTWNhO2bT8yoOdi83U4sG4RVBa8FsLJwJT3L7c=.b9df3624-35cd-469b-a8c3-b491e9ff4d60@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
 <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>
 <wW_GwuTWNhO2bT8yoOdi83U4sG4RVBa8FsLJwJT3L7c=.b9df3624-35cd-469b-a8c3-b491e9ff4d60@github.com>
Message-ID: <Ad--txWBTO9W3e0N61S2A8sfLQIVoqW3Dqa9LsoIkW0=.db001983-a807-45bc-a5e6-dc0e8b261b57@github.com>

On Mon, 20 Jan 2025 14:55:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> As far as I understand the change, this change prevents "back-to-back" GCs, opting for allocating everything into the old generation (if not full) instead.

I would not say this patch prefers allocation-in-old-gen over running gc. The behavior is governed by `GCTimeRatio`. One can get back the original behavior with a small `GCTimeRatio`.

> Did you run some other benchmarks with this change? (Maybe the smaller dacapo benchmarks at "reasonably" sized heaps will show something?)

Tried dacapo bms but no perf diff using 2x-live-size heap sizes. (This patch mostly affects the back-to-back gc case, which should be rare in properly configured system/bms.)

> It seems to fix a (rare?) policy issue, but at the same time adds a new mechanic (use of GCTimeRatio) for Serial GC.

Currently, there is no way to tune Serial based on app-vs-gc time, and this patch essentially adds that support.

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

PR Comment: https://git.openjdk.org/jdk/pull/22899#issuecomment-2603158491

From kirk at kodewerk.com  Mon Jan 20 20:26:11 2025
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Mon, 20 Jan 2025 21:26:11 +0100
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC [v2]
In-Reply-To: <Ad--txWBTO9W3e0N61S2A8sfLQIVoqW3Dqa9LsoIkW0=.db001983-a807-45bc-a5e6-dc0e8b261b57@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
 <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>
 <wW_GwuTWNhO2bT8yoOdi83U4sG4RVBa8FsLJwJT3L7c=.b9df3624-35cd-469b-a8c3-b491e9ff4d60@github.com>
 <Ad--txWBTO9W3e0N61S2A8sfLQIVoqW3Dqa9LsoIkW0=.db001983-a807-45bc-a5e6-dc0e8b261b57@github.com>
Message-ID: <79DF8C36-CEF1-4D9F-ABE8-6C4D0516B018@kodewerk.com>

Hi,


> On Jan 20, 2025, at 9:05?PM, Albert Mingkun Yang <ayang at openjdk.org> wrote:
> 
> On Mon, 20 Jan 2025 14:55:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> 
>> As far as I understand the change, this change prevents "back-to-back" GCs, opting for allocating everything into the old generation (if not full) instead.
> 
> I would not say this patch prefers allocation-in-old-gen over running gc. The behavior is governed by `GCTimeRatio`. One can get back the original behavior with a small `GCTimeRatio`.
> 
>> Did you run some other benchmarks with this change? (Maybe the smaller dacapo benchmarks at "reasonably" sized heaps will show something?)
> 
> Tried dacapo bms but no perf diff using 2x-live-size heap sizes. (This patch mostly affects the back-to-back gc case, which should be rare in properly configured system/bms.)
> 
>> It seems to fix a (rare?) policy issue, but at the same time adds a new mechanic (use of GCTimeRatio) for Serial GC.
> 
> Currently, there is no way to tune Serial based on app-vs-gc time, and this patch essentially adds that support.

This is counter to my experience. If young gen is properly tuned, GC overhead is generally minimalized. IME, this is the third most optimal way to control GC overhead. Using GCTimeRatio is way down on that list given the current implementations.

Kind regards,
Kirk


From ayang at openjdk.org  Tue Jan 21 09:22:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Jan 2025 09:22:36 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC
In-Reply-To: <79DF8C36-CEF1-4D9F-ABE8-6C4D0516B018@kodewerk.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
 <79DF8C36-CEF1-4D9F-ABE8-6C4D0516B018@kodewerk.com>
Message-ID: <u3qfdaY3ePs7hQfAiC9B40-NbfLbNIMlG3UZ9HcMWIg=.c39cb82a-3e23-4444-8c01-248858a59305@github.com>

On Mon, 20 Jan 2025 20:27:28 GMT, Kirk Pepperdine <kirk at kodewerk.com> wrote:

> If young gen is properly tuned, GC overhead is generally minimalized.

That approach is inflexible and requires trial and error, as it depends on knowing the allocation rate. The GC percentage (`GCTimeRatio`) provides a more direct way to express that requirement or intention.

> Using GCTimeRatio is way down on that list given the current implementations.

Serial doesn't support `GCTimeRatio`; this PR aims to add support for it in Serial. In the long run, as I envision it, once Serial implements auto-heap-resizing, `MaxGCPauseMillis` and `GCTimeRatio` will become the two primary flags for controlling GC.

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

PR Comment: https://git.openjdk.org/jdk/pull/22899#issuecomment-2604129892

From ayang at openjdk.org  Tue Jan 21 09:57:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Jan 2025 09:57:15 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses
Message-ID: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>

Simple refactoring of removing the use of `virtual` method and use concrete subclasses when needed.

Test: tier1-5

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

Commit messages:
 - gen-counter

Changes: https://git.openjdk.org/jdk/pull/23209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348171
  Stats: 195 lines in 16 files changed: 8 ins; 157 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/23209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23209/head:pull/23209

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

From ayang at openjdk.org  Tue Jan 21 14:43:57 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Jan 2025 14:43:57 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v2]
In-Reply-To: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
Message-ID: <ftzWhSa3GNKdOL-uB9velHPnXqlbr7F08ljiYB-7uY8=.13a224cc-93b3-4425-a57a-67e0e0ad3257@github.com>

> Simple refactoring of removing the use of `virtual` method and use concrete subclasses when needed.
> 
> Test: tier1-5

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 two commits:

 - merge
 - gen-counter

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

Changes: https://git.openjdk.org/jdk/pull/23209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23209&range=01
  Stats: 194 lines in 16 files changed: 8 ins; 156 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/23209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23209/head:pull/23209

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

From zgu at openjdk.org  Tue Jan 21 15:53:01 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 21 Jan 2025 15:53:01 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v5]
In-Reply-To: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
Message-ID: <jw2JO1tRma8p58ImXboM86u5hTywVURMcnK-GaH9sbg=.95a74a5c-1fc1-40cd-83fd-8952366df600@github.com>

> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
> 
> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.

Zhengyu Gu 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 17 additional commits since the last revision:

 - Yang's comment
 - Merge branch 'master' into JDK-8339668
 - Adopt latest PartialArrayStats changes
 - Merge branch 'master' into JDK-8339668
 - Merge branch 'master' into JDK-8339668
 - @tschatzl's ScannerTask changes
 - @tschatzl's comment
 - v8
 - v7
 - v6
 - ... and 7 more: https://git.openjdk.org/jdk/compare/1203c1a7...332c1cdd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21089/files
  - new: https://git.openjdk.org/jdk/pull/21089/files/0ed1a358..332c1cdd

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

  Stats: 52336 lines in 3084 files changed: 19535 ins; 21788 del; 11013 mod
  Patch: https://git.openjdk.org/jdk/pull/21089.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21089/head:pull/21089

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

From gli at openjdk.org  Tue Jan 21 16:46:08 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 21 Jan 2025 16:46:08 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
Message-ID: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>

Hi all,

This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .

Thanks for the review.

Best Regards,
-- Gouxiong

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

Commit messages:
 - JDK-8331723

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

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

From gli at openjdk.org  Tue Jan 21 16:49:36 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 21 Jan 2025 16:49:36 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
Message-ID: <MwXZ5GBoWvr2KRiwCKk1UBOsDcxhazHt8gIXat8Bxa4=.138238a0-1aa1-4ec5-8304-6d6bed288bbd@github.com>

On Tue, 21 Jan 2025 16:41:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
> 
> Thanks for the review.
> 
> Best Regards,
> -- Gouxiong

I want to mark @xiaotaonan as a contributor, but I don't know @xiaotaonan 's full name and email now.

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

PR Comment: https://git.openjdk.org/jdk/pull/23218#issuecomment-2605243968

From kvn at openjdk.org  Tue Jan 21 16:44:36 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 21 Jan 2025 16:44:36 GMT
Subject: RFR: 8347563: C2: clean up ModRefBarrierSetC2
In-Reply-To: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
References: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
Message-ID: <hjrU7I6uURF1fVNn9bPXmBVIyS24T53R0YzeW09JfEA=.0bca6fff-0d5c-433f-9370-c44585a01588@github.com>

On Tue, 14 Jan 2025 17:47:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup removes `ModRefBarrierSetC2::pre_barrier()` (which is a no-op after [JDK-8334060](https://bugs.openjdk.org/browse/JDK-8334060)) and unused arguments of `ModRefBarrierSetC2::post_barrier()`. Thanks to @TobiHartmann for reporting!
> 
> **Testing:** tier1-3.

Looks good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23112#pullrequestreview-2565178438

From ayang at openjdk.org  Tue Jan 21 17:26:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Jan 2025 17:26:35 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
Message-ID: <WKYO8hOTC3OO_Q6I1dk2h9XCGSclTdvWLjrMK1iRgso=.9a95e479-fae3-4e3c-b08b-2fad1b367948@github.com>

On Tue, 21 Jan 2025 16:41:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
> 
> Thanks for the review.
> 
> Best Regards,
> -- Gouxiong

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23218#pullrequestreview-2565281081

From zgu at openjdk.org  Wed Jan 22 02:26:03 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 22 Jan 2025 02:26:03 GMT
Subject: RFR: 8348241: ZGC: Unnecessarily reinitialize ZFragmentationLimit's
 default value
Message-ID: <FUItSyk33TSFKKoHGcYCF_n-dM4HmtSFNN4BoO5_WDc=.e9cf556c-3e55-44e3-a2de-6140cdf929df@github.com>

Please review this trivial change to remove unnecessary reinitializing  ZFragmentationLimit's default value. Looks like a leftover from [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692)

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

Commit messages:
 - 8348241: ZGC: Unnecessarily reinitialize ZFragmentationLimit's default value

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

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

From stefank at openjdk.org  Wed Jan 22 08:57:41 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jan 2025 08:57:41 GMT
Subject: RFR: 8348241: ZGC: Unnecessarily reinitialize
 ZFragmentationLimit's default value
In-Reply-To: <FUItSyk33TSFKKoHGcYCF_n-dM4HmtSFNN4BoO5_WDc=.e9cf556c-3e55-44e3-a2de-6140cdf929df@github.com>
References: <FUItSyk33TSFKKoHGcYCF_n-dM4HmtSFNN4BoO5_WDc=.e9cf556c-3e55-44e3-a2de-6140cdf929df@github.com>
Message-ID: <qGyAATjgYkR9TiLnxJ9V8Qxs279wgpKu1VXuS5eXNRg=.59f8b34c-b0bc-4e66-976d-2f37b7fe1937@github.com>

On Wed, 22 Jan 2025 02:19:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial change to remove unnecessary reinitializing  ZFragmentationLimit's default value. Looks like a leftover from [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692)

Looks good. Thanks for fixing!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23225#pullrequestreview-2566573730

From stefank at openjdk.org  Wed Jan 22 09:12:46 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jan 2025 09:12:46 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
Message-ID: <RPt8t-Htek1NmjEjAdau-VgFflbkDowwHUzxsULwcZk=.32e2f511-144f-4602-95fb-27069f799c85@github.com>

On Tue, 21 Jan 2025 16:41:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
> 
> Thanks for the review.
> 
> Best Regards,
> -- Gouxiong

I don't know why the bots are complaining about the contributor command, but please make sure to solve that before proceeding with this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23218#issuecomment-2606669458

From ayang at openjdk.org  Wed Jan 22 11:26:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 22 Jan 2025 11:26:46 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v5]
In-Reply-To: <jw2JO1tRma8p58ImXboM86u5hTywVURMcnK-GaH9sbg=.95a74a5c-1fc1-40cd-83fd-8952366df600@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
 <jw2JO1tRma8p58ImXboM86u5hTywVURMcnK-GaH9sbg=.95a74a5c-1fc1-40cd-83fd-8952366df600@github.com>
Message-ID: <rbsVqQ47lPQ7ieH1qU3MqFn74Hs0Ma351-_1IZlMLMk=.e98eb360-92a6-491a-ad81-60094f43e685@github.com>

On Tue, 21 Jan 2025 15:53:01 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
>> 
>> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.
>
> Zhengyu Gu 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 17 additional commits since the last revision:
> 
>  - Yang's comment
>  - Merge branch 'master' into JDK-8339668
>  - Adopt latest PartialArrayStats changes
>  - Merge branch 'master' into JDK-8339668
>  - Merge branch 'master' into JDK-8339668
>  - @tschatzl's ScannerTask changes
>  - @tschatzl's comment
>  - v8
>  - v7
>  - v6
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/7db80e2d...332c1cdd

src/hotspot/share/gc/parallel/psCompactionManager.cpp line 43:

> 41: #include "oops/objArrayKlass.inline.hpp"
> 42: #include "oops/oop.inline.hpp"
> 43: #include "utilities/checkedCast.hpp"

Can this be removed now?

src/hotspot/share/gc/parallel/psCompactionManager.cpp line 61:

> 59: ParCompactionManager::ParCompactionManager(PreservedMarks* preserved_marks,
> 60:                                            ReferenceProcessor* ref_processor)
> 61:   :_partial_array_splitter(_partial_array_state_manager, ParallelScavengeHeap::heap()->workers().max_workers()),

I would probably pass `parallel_gc_threads` into the constructor of `ParCompactionManager`, instead of calling `max_workers()` directly here, in order to maintain a single source of truth. YMMV.

src/hotspot/share/gc/parallel/psCompactionManager.cpp line 128:

> 126:   size_t array_length = obj_array->length();
> 127:   size_t initial_chunk_size =
> 128:     // The destination array is unused when processing states.

This comment is not very helpful; I had to look into the callee to find out it's referring to `nullptr` in the args and why one can use `nullptr` here, but that process is fairly straightforward, so this comment can probably be dropped.

src/hotspot/share/gc/shared/taskqueue.hpp line 566:

> 564: // Discriminated union over oop/oop*, narrowOop*, and PartialArrayState.
> 565: // Uses a low tag in the associated pointer to identify the category.
> 566: // Oop/oop* are overloaded using the same tag because they can not appear at the

The reason why "they can not appear at the same time" is that one is for young-gc and the other full-gc, right? If so, maybe state that explicitly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1925139586
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1925155413
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1925149603
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1925151953

From rcastanedalo at openjdk.org  Wed Jan 22 12:32:46 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 22 Jan 2025 12:32:46 GMT
Subject: RFR: 8347563: C2: clean up ModRefBarrierSetC2
In-Reply-To: <hjrU7I6uURF1fVNn9bPXmBVIyS24T53R0YzeW09JfEA=.0bca6fff-0d5c-433f-9370-c44585a01588@github.com>
References: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
 <hjrU7I6uURF1fVNn9bPXmBVIyS24T53R0YzeW09JfEA=.0bca6fff-0d5c-433f-9370-c44585a01588@github.com>
Message-ID: <ELNuLpEk0kmmOzIkRVfSgHNftI8znWvlJur7cit5upc=.747236b0-8ba5-4750-9121-69d3406a5e66@github.com>

On Tue, 21 Jan 2025 16:41:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Looks good.

Thanks, Vladimir!

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

PR Comment: https://git.openjdk.org/jdk/pull/23112#issuecomment-2607121546

From rcastanedalo at openjdk.org  Wed Jan 22 12:32:47 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 22 Jan 2025 12:32:47 GMT
Subject: Integrated: 8347563: C2: clean up ModRefBarrierSetC2
In-Reply-To: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
References: <-gmAzgAbpRH1w38vTKaK-Zqa7c5_116Y1KRrutQUn7M=.da413a60-e541-44d7-9822-bd4945beca36@github.com>
Message-ID: <RPX8u0n6hqoTgkyz0NywcXgPbGniIrWTj5xWmxhLCGM=.3ff68bec-1718-4fd1-888c-69a7c9024c37@github.com>

On Tue, 14 Jan 2025 17:47:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup removes `ModRefBarrierSetC2::pre_barrier()` (which is a no-op after [JDK-8334060](https://bugs.openjdk.org/browse/JDK-8334060)) and unused arguments of `ModRefBarrierSetC2::post_barrier()`. Thanks to @TobiHartmann for reporting!
> 
> **Testing:** tier1-3.

This pull request has now been integrated.

Changeset: 1c7641d4
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c7641d44f9891b632bcd471edae252103ffb95c
Stats:     60 lines in 4 files changed: 0 ins; 54 del; 6 mod

8347563: C2: clean up ModRefBarrierSetC2

Reviewed-by: ayang, tschatzl, kvn

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

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

From ayang at openjdk.org  Wed Jan 22 13:18:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 22 Jan 2025 13:18:34 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <RPt8t-Htek1NmjEjAdau-VgFflbkDowwHUzxsULwcZk=.32e2f511-144f-4602-95fb-27069f799c85@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
 <RPt8t-Htek1NmjEjAdau-VgFflbkDowwHUzxsULwcZk=.32e2f511-144f-4602-95fb-27069f799c85@github.com>
Message-ID: <m7-omz49nGivx_yXPmIALJtMKtFpN9pc80eCDWNFosg=.9aaf25d5-f988-4cf9-b7dd-4790e3264bb9@github.com>

On Wed, 22 Jan 2025 09:09:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I don't know why the bots are complaining

I believe the user is not in census and "Github and OpenJDK usernames can only be used for users in the OpenJDK [census](https://openjdk.java.net/census)", according to https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/contributor

I can see no email address on the user's profile page (https://github.com/xiaotaonan), so don't know how to get in contact with xiaotaonan.

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

PR Comment: https://git.openjdk.org/jdk/pull/23218#issuecomment-2607223823

From stefank at openjdk.org  Wed Jan 22 15:13:59 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jan 2025 15:13:59 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <MwXZ5GBoWvr2KRiwCKk1UBOsDcxhazHt8gIXat8Bxa4=.138238a0-1aa1-4ec5-8304-6d6bed288bbd@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
 <MwXZ5GBoWvr2KRiwCKk1UBOsDcxhazHt8gIXat8Bxa4=.138238a0-1aa1-4ec5-8304-6d6bed288bbd@github.com>
Message-ID: <7iYSJBhXbfZh4poR0hoTUSFVBcabKNm_EmKlpkrmIts=.52a84e3b-cf53-451f-aad2-a2adcff2a59c@github.com>

On Tue, 21 Jan 2025 16:46:30 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Gouxiong
>
> I want to mark @xiaotaonan as a contributor, but I don't know @xiaotaonan 's full name and email now.

@lgxbslgx How did you get this mail address? Could @xiaotaonan please verify that this is correct?

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

PR Comment: https://git.openjdk.org/jdk/pull/23218#issuecomment-2607509047

From rcastanedalo at openjdk.org  Wed Jan 22 15:30:35 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 22 Jan 2025 15:30:35 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
Message-ID: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>

G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.

The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:


o = new MyObject();
if (...) {
    o.myField = ...;  // barrier elided only after this changeset
                      // (assuming no safepoint in the if condition)
}


or in initialization writes placed after exception-throwing checks:


o = new MyObject();
if (...) {
    throw new Exception("");
}
o.myField = ...;  // barrier elided only after this changeset
                  // (assuming no safepoint in the above if condition)


These patterns are commonly found in Java code, e.g. in the core libraries:

- [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or

- [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).

The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):


Object[] a = new Object[...];
for (int i = 0; i < a.length; i++) {
    a[i] = ...;  // barrier elided only after this changeset
}


or eliding barriers from array initialization writes with unknown array index:


Object[] a = new Object[...];
a[index] = ...;  // barrier elided only after this changeset


The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array_allocation`, and `is_allocation` are simply moved from one file to the other. The function `analyze_dominating_barriers_impl` is moved and renamed to `elide_dominated_barriers` for clarity.

#### Testing

##### Functionality

- tier1-5, stress testing (linux-x64, windows-x64, macosx-x64, linux-aarch64, macosx-aarch64; release and debug mode).

##### Performance

- Tested performance on a set of standard benchmark suites (DaCapo, Renaissance, SPECjbb2015, SPECjvm2008). No significant change was observed, besides a slight positive overall trend for Renaissance.

- Profiled dynamic count of writes with barriers elided by this changeset using DaCapo on linux-x64. Late elision manages to elide around 15% of all executed barriers for the `jython` and `kafka` benchmarks, almost 10% for `xalan`, and less than 5% for the remaining benchmarks.

- Measured execution overhead of late elision using DaCapo on linux-x64. The new optimization takes, on average, less than 0.2% of the total C2 execution time.

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

Commit messages:
 - Add new test case (store after exception)
 - Remove unused includes
 - Remove temporary UseNewCode guard
 - Use clearer names and document access API interface
 - Move ZGC-specific barrier elision code to BarrierSetC2
 - Set UseNewCode to true temporarily
 - Make elide_mach_barrier virtual
 - Move late barrier elision analysis from G1BarrierSetC2 to BarrierSetC2
 - Initial implementation
 - Add more G1 barrier elision tests, expect G1-specific memory accesses with no barrier data as an alternative to generic memory accesses

Changes: https://git.openjdk.org/jdk/pull/23235/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346280
  Stats: 773 lines in 9 files changed: 492 ins; 262 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23235/head:pull/23235

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

From rcastanedalo at openjdk.org  Wed Jan 22 15:35:50 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 22 Jan 2025 15:35:50 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <ht6CQfBUvYRuBfkLZlwBqlq2TGwXJ1sxVabnQMY553o=.1d230253-2dc8-44e4-bbd0-0ab154bc87a2@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

@TheRealMDoerr @offamitkumar @RealFYang @snazarkin could you please test this changeset (and in particular run the additional tests in `compiler/gcbarriers/TestG1BarrierGeneration.java`) in the non-Oracle supported platforms? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2607566644

From zgu at openjdk.org  Thu Jan 23 01:17:51 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 23 Jan 2025 01:17:51 GMT
Subject: RFR: 8348241: ZGC: Unnecessarily reinitialize
 ZFragmentationLimit's default value
In-Reply-To: <FUItSyk33TSFKKoHGcYCF_n-dM4HmtSFNN4BoO5_WDc=.e9cf556c-3e55-44e3-a2de-6140cdf929df@github.com>
References: <FUItSyk33TSFKKoHGcYCF_n-dM4HmtSFNN4BoO5_WDc=.e9cf556c-3e55-44e3-a2de-6140cdf929df@github.com>
Message-ID: <1JCKvWdIz7flrF5xlZHH1iD0_I-vG2ChwLd1Th9ORXA=.63b6f32d-f956-4711-9e21-430669892177@github.com>

On Wed, 22 Jan 2025 02:19:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial change to remove unnecessary reinitializing  ZFragmentationLimit's default value. Looks like a leftover from [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692)

Thanks, @stefank

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

PR Comment: https://git.openjdk.org/jdk/pull/23225#issuecomment-2608635949

From zgu at openjdk.org  Thu Jan 23 01:17:52 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 23 Jan 2025 01:17:52 GMT
Subject: Integrated: 8348241: ZGC: Unnecessarily reinitialize
 ZFragmentationLimit's default value
In-Reply-To: <FUItSyk33TSFKKoHGcYCF_n-dM4HmtSFNN4BoO5_WDc=.e9cf556c-3e55-44e3-a2de-6140cdf929df@github.com>
References: <FUItSyk33TSFKKoHGcYCF_n-dM4HmtSFNN4BoO5_WDc=.e9cf556c-3e55-44e3-a2de-6140cdf929df@github.com>
Message-ID: <n7FELMYoZDXgAh5LgE1hGCJXU2AZvuJs97I9InIXsuo=.df7da21f-c9c4-4657-9840-95c1819fc227@github.com>

On Wed, 22 Jan 2025 02:19:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial change to remove unnecessary reinitializing  ZFragmentationLimit's default value. Looks like a leftover from [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692)

This pull request has now been integrated.

Changeset: a36e166e
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a36e166ec9e6d6063e5fbbc48555e33c2fa38f3a
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8348241: ZGC: Unnecessarily reinitialize ZFragmentationLimit's default value

Reviewed-by: stefank

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

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

From amitkumar at openjdk.org  Thu Jan 23 03:36:49 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 23 Jan 2025 03:36:49 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <z8hfKHqakBGAAnOLPf5BEpDm3h2ddWizCM1mYMVwSUc=.13a31b94-e96d-443a-b2ec-6521f87ae0e3@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

I ran tier1 on s390x and don't see any failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2608775458

From rcastanedalo at openjdk.org  Thu Jan 23 07:24:46 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 23 Jan 2025 07:24:46 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <z8hfKHqakBGAAnOLPf5BEpDm3h2ddWizCM1mYMVwSUc=.13a31b94-e96d-443a-b2ec-6521f87ae0e3@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <z8hfKHqakBGAAnOLPf5BEpDm3h2ddWizCM1mYMVwSUc=.13a31b94-e96d-443a-b2ec-6521f87ae0e3@github.com>
Message-ID: <_6IZUAUCBGw1v4ui6ibFq9M9RibfZbmZzzQ4Z708RI0=.93dd14ef-9168-4ca8-ad1e-00e94f2cb0f2@github.com>

On Thu, 23 Jan 2025 03:34:15 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> I ran tier1 on s390x and don't see any failures.

Thanks for testing, Amit!

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2609037729

From mdoerr at openjdk.org  Thu Jan 23 10:26:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 10:26:47 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <CcL1dAScYz4109H7KVzyjqqN1GIygI2tzbRlnnIEvTY=.7062a855-1fa9-4a1c-9cef-6a02a54be92b@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

We have seen many crashes in JFR tests like jdk/jfr/api/consumer/streaming/TestFilledChunks.java on PPC64:

#  SIGSEGV (0xb) at pc=0x00007fff9ef80948, pid=285054, tid=285751
# V  [libjvm.so+0x620948]  get_base_and_offset(MachNode const*, long&)+0x2c8

V  [libjvm.so+0x620948]  get_base_and_offset(MachNode const*, long&)+0x2c8  (type.hpp:994)
V  [libjvm.so+0x629e4c]  BarrierSetC2::is_allocation(Node const*)+0x10c  (barrierSetC2.cpp:1048)
V  [libjvm.so+0xd1c708]  G1BarrierSetC2::analyze_dominating_barriers() const+0x628  (g1BarrierSetC2.cpp:554)
V  [libjvm.so+0x17686d8]  PhaseOutput::perform_mach_node_analysis()+0xe8  (output.cpp:258)
V  [libjvm.so+0x177ceb4]  PhaseOutput::Output()+0xc74  (output.cpp:346)
V  [libjvm.so+0xa4b450]  Compile::Code_Gen()+0x650  (compile.cpp:3030)
V  [libjvm.so+0xa50100]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1c20  (compile.cpp:884)
V  [libjvm.so+0x7fb294]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1c4  (c2compiler.cpp:141)

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2609429034

From shade at openjdk.org  Thu Jan 23 11:33:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 23 Jan 2025 11:33:56 GMT
Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in default
 modes
Message-ID: <iA5-e4hKspjLBJAniBWfSl6A57zlBVUC5cMSsWY-ack=.29cab729-0abc-4a10-8050-a119d95860ff@github.com>

See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value.

I think cutting to 0.2% of RAM size gets us into good sweet spot:
 - On huge 1024G machine, this yields 2G initial heap
 - On reasonably sized 128G machine, this gives 256M initial heap
 - On smaller 1G container, this gives 2M initial heap

Additional testing:
 - [x] Linux AArch64 server fastdebug, `all`

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

Commit messages:
 - Fix

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

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

From stefank at openjdk.org  Thu Jan 23 12:40:06 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 23 Jan 2025 12:40:06 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge remote-tracking branch 'upstream/master' into 8346572_check_is_reserved
 - 8346572: Check is_reserved() before using ReservedSpace instances

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

Changes: https://git.openjdk.org/jdk/pull/22825/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22825&range=01
  Stats: 117 lines in 10 files changed: 47 ins; 31 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/22825.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22825/head:pull/22825

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

From rcastanedalo at openjdk.org  Thu Jan 23 13:03:47 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 23 Jan 2025 13:03:47 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <CcL1dAScYz4109H7KVzyjqqN1GIygI2tzbRlnnIEvTY=.7062a855-1fa9-4a1c-9cef-6a02a54be92b@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <CcL1dAScYz4109H7KVzyjqqN1GIygI2tzbRlnnIEvTY=.7062a855-1fa9-4a1c-9cef-6a02a54be92b@github.com>
Message-ID: <k-adytzp5TWWzQEbwpeBhVB-I02qtkdE--j4IR2Ayhs=.436d27f5-1d50-4953-b28b-68347c7beceb@github.com>

On Thu, 23 Jan 2025 10:24:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We have seen many crashes in JFR tests like jdk/jfr/api/consumer/streaming/TestFilledChunks.java on PPC64:
> 
> ```
> #  SIGSEGV (0xb) at pc=0x00007fff9ef80948, pid=285054, tid=285751
> # V  [libjvm.so+0x620948]  get_base_and_offset(MachNode const*, long&)+0x2c8
> 
> V  [libjvm.so+0x620948]  get_base_and_offset(MachNode const*, long&)+0x2c8  (type.hpp:994)
> V  [libjvm.so+0x629e4c]  BarrierSetC2::is_allocation(Node const*)+0x10c  (barrierSetC2.cpp:1048)
> V  [libjvm.so+0xd1c708]  G1BarrierSetC2::analyze_dominating_barriers() const+0x628  (g1BarrierSetC2.cpp:554)
> V  [libjvm.so+0x17686d8]  PhaseOutput::perform_mach_node_analysis()+0xe8  (output.cpp:258)
> V  [libjvm.so+0x177ceb4]  PhaseOutput::Output()+0xc74  (output.cpp:346)
> V  [libjvm.so+0xa4b450]  Compile::Code_Gen()+0x650  (compile.cpp:3030)
> V  [libjvm.so+0xa50100]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1c20  (compile.cpp:884)
> V  [libjvm.so+0x7fb294]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1c4  (c2compiler.cpp:141)
> ```

Thanks for the report, Martin. Have you tried running this test with ZGC? ZGC exercises the same logic (even before this changeset) so it could be subject to the same issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2609751843

From ayang at openjdk.org  Thu Jan 23 15:16:56 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 23 Jan 2025 15:16:56 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation before
 GC [v2]
In-Reply-To: <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
 <AWLh_H8YjqvCDgQZ8OtvkYDP8j3nfEcwMEk41rooH28=.aa130ba6-05fd-4864-8597-f4825fc14c70@github.com>
Message-ID: <DKglZ8wVIM_lObzTgGnWXm_189h1VCrkyaCrbbNVa4I=.c84a2db2-d99f-4b0d-bce8-7693bcc370eb@github.com>

On Mon, 6 Jan 2025 14:36:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR introduces a new strategy to determine whether an allocation should be attempted in the old generation or if a GC cycle should be initiated, based on the `GCTimeRatio`. With this change, the benchmark attached to the ticket now completes in ~13 GC, a significant improvement compared to the >1000 GC observed previously.
>> 
>> 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 s1-gc-time-ratio
>  - s1-gc-time-ratio

Superseded by https://github.com/openjdk/jdk/pull/23270, where it doesn't use `GCTimeRatio` and affects only tight-heap configurations.

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

PR Comment: https://git.openjdk.org/jdk/pull/22899#issuecomment-2610079116

From ayang at openjdk.org  Thu Jan 23 15:16:57 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 23 Jan 2025 15:16:57 GMT
Subject: Withdrawn: 8346920: Serial: Support allocation in old generation
 before GC
In-Reply-To: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
References: <iW8sCr_5g290YA4tKS1G0PmZMijf97-jFy3IqMYV3Nw=.4f3c800e-c7c8-4910-a6cc-a6ff0676fb34@github.com>
Message-ID: <ehaqIJB1p-hREg3QNAvB7kZwHsXp2rh8kVnbAanFOMY=.ee992c99-5a7c-4896-a76c-57ed88060bab@github.com>

On Thu, 2 Jan 2025 06:30:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR introduces a new strategy to determine whether an allocation should be attempted in the old generation or if a GC cycle should be initiated, based on the `GCTimeRatio`. With this change, the benchmark attached to the ticket now completes in ~13 GC, a significant improvement compared to the >1000 GC observed previously.
> 
> Test: tier1-3

This pull request has been closed without being integrated.

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

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

From ayang at openjdk.org  Thu Jan 23 15:17:27 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 23 Jan 2025 15:17:27 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when heap
 is almost full
Message-ID: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>

This PR restores the support for allocation in old-gen when heap is almost full, detected as non-empty young-gen after full gc, which was removed by mistake in [JDK-8333786](https://bugs.openjdk.org/browse/JDK-8333786). With this change, the benchmark attached to the ticket now completes in ~13 GC.

Test: tier1-5

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

Commit messages:
 - sgc-alloc-in-old

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

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

From mdoerr at openjdk.org  Thu Jan 23 16:22:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 16:22:47 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <2nOBv253rd3kNz31mi6zSQz7K7jmBzPF85mEMvEoy8k=.d6a94499-153c-4941-9144-75d30c32976f@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

You're right. We get the same crashes when running JFR tests with ZGC on PPC64. Seems like nobody has done this before.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2610288572

From mdoerr at openjdk.org  Thu Jan 23 16:43:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 16:43:50 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <Z-1MXuSIvDfH9dBWdr5drrzfk029JVeImMuW-Vrx7qQ=.555ce88b-d85b-4266-a115-5ccdebfc4f26@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

The slowdebug build shows a better stack trace:


V  [libjvm.so+0xa1a3f0]  TypePtr::offset() const+0x14  (type.hpp:994)
V  [libjvm.so+0x1d35288]  get_base_and_offset(MachNode const*, long&)+0xb0  (zBarrierSetC2.cpp:557)
V  [libjvm.so+0x1d35818]  is_allocation(Node const*)+0x108  (zBarrierSetC2.cpp:629)
V  [libjvm.so+0x1d36230]  ZBarrierSetC2::analyze_dominating_barriers() const+0x19c  (zBarrierSetC2.cpp:759)
V  [libjvm.so+0x1d33ea0]  ZBarrierSetC2::late_barrier_analysis() const+0x54  (zBarrierSetC2.cpp:307)
V  [libjvm.so+0x167d36c]  PhaseOutput::perform_mach_node_analysis()+0x60  (output.cpp:258)
V  [libjvm.so+0x167dc50]  PhaseOutput::Output()+0x890  (output.cpp:346)
V  [libjvm.so+0xa0a57c]  Compile::Code_Gen()+0x4e4  (compile.cpp:3030)
V  [libjvm.so+0x9fd51c]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x179c  (compile.cpp:884)
V  [libjvm.so+0x80a220]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1f0  (c2compiler.cpp:141)

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2610365334

From mdoerr at openjdk.org  Thu Jan 23 17:02:48 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 17:02:48 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <AHPOgrthrY4YQhi7vC7HWmS2G2CIQhGdBcI8G4fFs1w=.2fa36e26-c9b7-4256-99f1-1ac88666bd42@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

It can be fixed like this:

diff --git a/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp b/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
index 538e87a8f19..311ea2871f7 100644
--- a/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
+++ b/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
@@ -558,7 +558,9 @@ static const Node* get_base_and_offset(const MachNode* mach, intptr_t& offset) {
     // The memory address is computed by 'base' and fed to 'mach' via an
     // indirect memory operand (indicated by offset == 0). The ultimate base and
     // offset can be fetched directly from the inputs and Ideal type of 'base'.
-    offset = base->bottom_type()->isa_oopptr()->offset();
+    const TypeOopPtr* oopptr = base->bottom_type()->isa_oopptr();
+    if (oopptr == nullptr) return nullptr;
+    offset = oopptr->offset();
     // Even if 'base' is not an Ideal AddP node anymore, Matcher::ReduceInst()
     // guarantees that the base address is still available at the same slot.
     base = base->in(AddPNode::Base);

Do you want to include the fix and we file a separate issue for jdk24 and older?

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2610425833

From qamai at openjdk.org  Thu Jan 23 18:12:51 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 23 Jan 2025 18:12:51 GMT
Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in
 default modes
In-Reply-To: <iA5-e4hKspjLBJAniBWfSl6A57zlBVUC5cMSsWY-ack=.29cab729-0abc-4a10-8050-a119d95860ff@github.com>
References: <iA5-e4hKspjLBJAniBWfSl6A57zlBVUC5cMSsWY-ack=.29cab729-0abc-4a10-8050-a119d95860ff@github.com>
Message-ID: <3qSVdyJR6ozIeVTfuIoF8d6i2ETvOsxghb8lmvpjrCg=.ad527b3b-b250-49ab-b0c1-60a811aabf7f@github.com>

On Thu, 23 Jan 2025 11:27:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value.
> 
> I think cutting to 0.2% of RAM size gets us into good sweet spot:
>  - On huge 1024G machine, this yields 2G initial heap
>  - On reasonably sized 128G machine, this gives 256M initial heap
>  - On smaller 1G container, this gives 2M initial heap
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all`

I think it may be a little more preferrable to clamp this to some interval so that the value does not get unreasonably large or unreasonably small

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

PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-2610612688

From wkemper at openjdk.org  Thu Jan 23 18:17:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 23 Jan 2025 18:17:55 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
Message-ID: <52g1j3w9Wl6NwJqpJI-Im6Smp9wPb4IGtNkRpkTsPMI=.8d4cf740-4b91-4c0c-a957-b32c1d5bd85d@github.com>

On Thu, 23 Jan 2025 12:40:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
>> 
>> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
>> 
>> Tested tier1 and GHA, but will run more tests when/if this gets accepted.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8346572_check_is_reserved
>  - 8346572: Check is_reserved() before using ReservedSpace instances

Filed https://bugs.openjdk.org/browse/JDK-8348420 to follow up for Shenandoah.

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2570660032

From wkemper at openjdk.org  Thu Jan 23 21:41:19 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 23 Jan 2025 21:41:19 GMT
Subject: RFR: 8348400: GenShen:
 assert(ShenandoahHeap::heap()->is_full_gc_in_progress() ||
 (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity
 #
Message-ID: <r7p7OKmdrNDiab6ZQZ_6S35RH2rAKG5LajSxcFl6aC4=.b7e07485-4e63-4d47-9719-6c57df391561@github.com>

When the capacity of a trashed region is transferred from the young to old generation, we must first recycle the region to break its affiliation with the young generation. Failing to do this may violate the constraint that the capacity of a generation is always equal to or greater than the capacity of its affiliated regions.

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

Commit messages:
 - Recycle young trash region before flipping to GC

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

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

From kdnilsen at openjdk.org  Thu Jan 23 22:00:49 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 23 Jan 2025 22:00:49 GMT
Subject: RFR: 8348400: GenShen:
 assert(ShenandoahHeap::heap()->is_full_gc_in_progress() ||
 (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity
 #
In-Reply-To: <r7p7OKmdrNDiab6ZQZ_6S35RH2rAKG5LajSxcFl6aC4=.b7e07485-4e63-4d47-9719-6c57df391561@github.com>
References: <r7p7OKmdrNDiab6ZQZ_6S35RH2rAKG5LajSxcFl6aC4=.b7e07485-4e63-4d47-9719-6c57df391561@github.com>
Message-ID: <-HZ_SZQvC25R3YA915ld-p05tE21icdJflKmSnkeejw=.d61b807e-5eb9-48db-a0a4-5cf364a83c22@github.com>

On Thu, 23 Jan 2025 21:36:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When the capacity of a trashed region is transferred from the young to old generation, we must first recycle the region to break its affiliation with the young generation. Failing to do this may violate the constraint that the capacity of a generation is always equal to or greater than the capacity of its affiliated regions.

LGTM.  (Is there any way to "confirm" that this is the code path that caused the original JBS issue?)

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

Marked as reviewed by kdnilsen (Author).

PR Review: https://git.openjdk.org/jdk/pull/23282#pullrequestreview-2571111755

From fyang at openjdk.org  Fri Jan 24 01:26:47 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 24 Jan 2025 01:26:47 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <AN0gyM3hgKCrfJ5dXT0xhIA8vKJvYpU7BID_ly5tLbM=.5a607809-de9e-4b4b-870a-e515e55754ba@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

FYI: `gtest:all` and `tier1` results are clean on linux-riscv64 with this change.
And `compiler/gcbarriers/TestG1BarrierGeneration.java` passes with both release and fastdebug builds on this platform.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2611347452

From gli at openjdk.org  Fri Jan 24 01:55:47 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 24 Jan 2025 01:55:47 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
Message-ID: <TrpAZa6wp9PARkhsxYOSe3txd3YO9a9aIDLQLhFCdDc=.0e145706-90fb-4477-a598-af8eabf00115@github.com>

On Tue, 21 Jan 2025 16:41:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
> 
> Thanks for the review.
> 
> Best Regards,
> -- Gouxiong

I contact with @xiaotaonan in WeChat (a communication software). The full name and  email is provided by himself.

![IMG_3543](https://github.com/user-attachments/assets/cd059ad1-24b6-48d8-9d20-1c301fd9277c)

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

PR Comment: https://git.openjdk.org/jdk/pull/23218#issuecomment-2611376085

From snazarki at openjdk.org  Fri Jan 24 07:42:47 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 24 Jan 2025 07:42:47 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <VC4EBHv2ys1JXRqwtopTgBL54RzNNtiMosgcL8UWv44=.215ff931-082a-4d1b-815a-3ffd8ab57b50@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

I observe several test failures on arm32. Investigating the problem

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2611857946

From sjohanss at openjdk.org  Fri Jan 24 09:08:54 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 24 Jan 2025 09:08:54 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full
In-Reply-To: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
Message-ID: <I_4SvPsBN62C18TQeTn1iNEJlASX0EMSSswWm5Fofg4=.458cc234-4c86-479b-b0d7-996b5c1b8a2f@github.com>

On Thu, 23 Jan 2025 15:12:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR restores the support for allocation in old-gen when heap is almost full, detected as non-empty young-gen after full gc, which was removed by mistake in [JDK-8333786](https://bugs.openjdk.org/browse/JDK-8333786). With this change, the benchmark attached to the ticket now completes in ~13 GC.
> 
> Test: tier1-5

Looks good, just a few suggestions.

src/hotspot/share/gc/serial/serialHeap.cpp line 293:

> 291:   return    (word_size > heap_word_size(young_capacity))
> 292:          || GCLocker::is_active_and_needs_gc()
> 293:          || _is_heap_almost_full;

Maybe update the comment above to be even more accurate.

src/hotspot/share/gc/serial/serialHeap.hpp line 103:

> 101:   // will attempt some uncommon measures, e.g. alllocating small objs in
> 102:   // old-gen.
> 103:   bool _is_heap_almost_full;

I'm not to fond of the `heap` part of the name since it lives in `SerialHeap`, but just calling it `_is_almost_full` will look strange since we also have the parameter `full` where it is used. 

What do you think about calling it something like `_allow_old_gen_allocation` instead?

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

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23270#pullrequestreview-2572069193
PR Review Comment: https://git.openjdk.org/jdk/pull/23270#discussion_r1928350924
PR Review Comment: https://git.openjdk.org/jdk/pull/23270#discussion_r1928357467

From stefank at openjdk.org  Fri Jan 24 09:11:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 24 Jan 2025 09:11:52 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
Message-ID: <SAF8HLQNenvbDGaa07u_dKeYcWnCCJEYxdxuGgH_eZY=.e7b68b51-73c6-41c3-bf75-e62d9f761afe@github.com>

On Thu, 23 Jan 2025 12:40:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
>> 
>> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
>> 
>> Tested tier1 and GHA, but will run more tests when/if this gets accepted.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8346572_check_is_reserved
>  - 8346572: Check is_reserved() before using ReservedSpace instances

Thank you all!

Tier1-3 testing passed again.

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

PR Comment: https://git.openjdk.org/jdk/pull/22825#issuecomment-2612021846

From tschatzl at openjdk.org  Fri Jan 24 09:26:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Jan 2025 09:26:54 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
Message-ID: <W0x5jZioyVHNK1Ngoi4-QUJ-2kYXgJEl5f8SAMA7viU=.a008f770-54f5-46a6-a430-629ca4e86d11@github.com>

On Thu, 23 Jan 2025 12:40:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
>> 
>> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
>> 
>> Tested tier1 and GHA, but will run more tests when/if this gets accepted.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8346572_check_is_reserved
>  - 8346572: Check is_reserved() before using ReservedSpace instances

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2572119144

From stefank at openjdk.org  Fri Jan 24 09:26:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 24 Jan 2025 09:26:55 GMT
Subject: Integrated: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <As9oR1hixVKX0Coh9BPH7vRG-RFDVwJRU9M8Rewr8k8=.bf7e9c45-3a52-4a21-8c21-aea03a5f8aed@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

This pull request has now been integrated.

Changeset: 0df9dcb6
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0df9dcb6aa7c31511ca3137da246962faca818a3
Stats:     117 lines in 10 files changed: 47 ins; 31 del; 39 mod

8346572: Check is_reserved() before using ReservedSpace instances

Reviewed-by: tschatzl, wkemper, ayang, ysr

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

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

From stefank at openjdk.org  Fri Jan 24 09:30:50 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 24 Jan 2025 09:30:50 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
Message-ID: <54P1hkjdyuqSav8HGMjgqUDXsIhKxduhJW4OjhaZoq0=.ca1774e9-a8f6-4acd-b23d-28c39698ea0b@github.com>

On Tue, 21 Jan 2025 16:41:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
> 
> Thanks for the review.
> 
> Best Regards,
> -- Gouxiong

OK. So, the the first email address was not the right mail address then. I've double checked that the username and email address matches our OCA records.

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

PR Comment: https://git.openjdk.org/jdk/pull/23218#issuecomment-2612058976

From rcastanedalo at openjdk.org  Fri Jan 24 09:38:49 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 24 Jan 2025 09:38:49 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <AN0gyM3hgKCrfJ5dXT0xhIA8vKJvYpU7BID_ly5tLbM=.5a607809-de9e-4b4b-870a-e515e55754ba@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <AN0gyM3hgKCrfJ5dXT0xhIA8vKJvYpU7BID_ly5tLbM=.5a607809-de9e-4b4b-870a-e515e55754ba@github.com>
Message-ID: <oJPyfCtIQ4N8pV8tU-yFkUwQa6BQ_V_fs-b2FCYEBYg=.c94cd5e0-89ea-47e7-940a-0a82628cebce@github.com>

On Fri, 24 Jan 2025 01:23:58 GMT, Fei Yang <fyang at openjdk.org> wrote:

> FYI: `gtest:all` and `tier1` results are clean on linux-riscv64 with this change. And `compiler/gcbarriers/TestG1BarrierGeneration.java` passes with both release and fastdebug builds on this platform.

Thanks for testing @RealFYang!

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2612074571

From rcastanedalo at openjdk.org  Fri Jan 24 09:38:48 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 24 Jan 2025 09:38:48 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <yoOsM05xCJEnJsHqnFqj14vrnn50E1A1WCY6gAOnEuw=.ac041bfa-a3b1-4f1c-8d27-0417a072487c@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

> It can be fixed like this:
> 
> ```diff
> diff --git a/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp b/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
> index 538e87a8f19..311ea2871f7 100644
> --- a/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
> +++ b/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
> @@ -558,7 +558,9 @@ static const Node* get_base_and_offset(const MachNode* mach, intptr_t& offset) {
>      // The memory address is computed by 'base' and fed to 'mach' via an
>      // indirect memory operand (indicated by offset == 0). The ultimate base and
>      // offset can be fetched directly from the inputs and Ideal type of 'base'.
> -    offset = base->bottom_type()->isa_oopptr()->offset();
> +    const TypeOopPtr* oopptr = base->bottom_type()->isa_oopptr();
> +    if (oopptr == nullptr) return nullptr;
> +    offset = oopptr->offset();
>      // Even if 'base' is not an Ideal AddP node anymore, Matcher::ReduceInst()
>      // guarantees that the base address is still available at the same slot.
>      base = base->in(AddPNode::Base);
> ```
> 
> Do you want to include the fix and we file a separate issue for jdk24 and older?

Thanks Martin! I agree with your analysis and proposed solution. I have reported the issue ([JDK-8348562](https://bugs.openjdk.org/browse/JDK-8348562)) and assigned it to you, feel free to assign back if you prefer me to submit the fix. Since we are not in a hurry with this RFE, I think I will simply wait until JDK-8348562 is integrated to update this changeset.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2612073374

From mdoerr at openjdk.org  Fri Jan 24 10:43:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Jan 2025 10:43:47 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <wHpelszhSw8AcnxWcX1xcNlstYSmParNGirOnsXrRIE=.a2ef1520-5860-4635-8385-f8314e02166b@github.com>

On Wed, 22 Jan 2025 15:20:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

I agree with your suggestion. I've created https://github.com/openjdk/jdk/pull/23295. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2612211686

From mdoerr at openjdk.org  Fri Jan 24 10:44:22 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Jan 2025 10:44:22 GMT
Subject: RFR: 8348562: ZGC: segmentation fault due to missing node type check
 in barrier elision analysis
Message-ID: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>

Adding the missing node type check as described in the JBS issue. `oopptr` can be null in which case the current implementation crashes. This was only reported for JFR tests on PPC64 so far. If the expected graph pattern is not found, we bail out and skip the optimization.

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

Commit messages:
 - 8348562: ZGC: segmentation fault due to missing node type check in barrier elision analysis

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

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

From ayang at openjdk.org  Fri Jan 24 11:14:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 24 Jan 2025 11:14:01 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full [v2]
In-Reply-To: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
Message-ID: <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>

> This PR restores the support for allocation in old-gen when heap is almost full, detected as non-empty young-gen after full gc, which was removed by mistake in [JDK-8333786](https://bugs.openjdk.org/browse/JDK-8333786). With this change, the benchmark attached to the ticket now completes in ~13 GC.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23270/files
  - new: https://git.openjdk.org/jdk/pull/23270/files/30323d46..ec3da733

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

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

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

From gli at openjdk.org  Fri Jan 24 11:16:51 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 24 Jan 2025 11:16:51 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
Message-ID: <k_YZJ_39xB6gOjVq88yF609qcUZwCPXjM6pjnkhvP8E=.85ceeadf-647b-4405-ae38-6b1d59271bed@github.com>

On Tue, 21 Jan 2025 16:41:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
> 
> Thanks for the review.
> 
> Best Regards,
> -- Gouxiong

Should we need another review in this PR? If not, I will integrate it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23218#issuecomment-2612273856

From ayang at openjdk.org  Fri Jan 24 11:18:54 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 24 Jan 2025 11:18:54 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full [v2]
In-Reply-To: <I_4SvPsBN62C18TQeTn1iNEJlASX0EMSSswWm5Fofg4=.458cc234-4c86-479b-b0d7-996b5c1b8a2f@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
 <I_4SvPsBN62C18TQeTn1iNEJlASX0EMSSswWm5Fofg4=.458cc234-4c86-479b-b0d7-996b5c1b8a2f@github.com>
Message-ID: <sNbBPS9gi_y9vtL2f_x6HJCqWY5lwq41qqGqnWtoVX0=.7b6b1276-7938-484f-b231-4cb3da3f51da@github.com>

On Fri, 24 Jan 2025 09:04:24 GMT, Stefan Johansson <sjohanss 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/serialHeap.hpp line 103:
> 
>> 101:   // will attempt some uncommon measures, e.g. alllocating small objs in
>> 102:   // old-gen.
>> 103:   bool _is_heap_almost_full;
> 
> I'm not to fond of the `heap` part of the name since it lives in `SerialHeap`, but just calling it `_is_almost_full` will look strange since we also have the parameter `full` where it is used. 
> 
> What do you think about calling it something like `_allow_old_gen_allocation` instead?

This field is meant to convey what the situation is, and how to handle this situation is decided in callers with some context.

Naming it `_allow_old_gen_allocation` would mix up what it is and what to do with that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23270#discussion_r1928525148

From ayang at openjdk.org  Fri Jan 24 12:22:47 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 24 Jan 2025 12:22:47 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
Message-ID: <fs3fILHgNoH37O76q-0JhkZZ-XDeJ9JAnEQUAr4FAtM=.94b8b26b-d121-4716-89dc-3c0e499d2ab7@github.com>

On Tue, 21 Jan 2025 16:41:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
> 
> Thanks for the review.
> 
> Best Regards,
> -- Gouxiong

I think this is trivial. Feel free to merge.

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

PR Comment: https://git.openjdk.org/jdk/pull/23218#issuecomment-2612397944

From rcastanedalo at openjdk.org  Fri Jan 24 12:47:49 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 24 Jan 2025 12:47:49 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <VC4EBHv2ys1JXRqwtopTgBL54RzNNtiMosgcL8UWv44=.215ff931-082a-4d1b-815a-3ffd8ab57b50@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <VC4EBHv2ys1JXRqwtopTgBL54RzNNtiMosgcL8UWv44=.215ff931-082a-4d1b-815a-3ffd8ab57b50@github.com>
Message-ID: <g3zENUK4NQvVB9auDuJ9xiw2AR3bYVcUFZpbgMgqBfM=.f8e724d5-b137-47a4-ace0-0c10800c9ede@github.com>

On Fri, 24 Jan 2025 07:40:16 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> I observe several test failures on arm32. Investigating the problem

Thanks Sergey, please find my response to your questions offline.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2612448013

From gli at openjdk.org  Fri Jan 24 12:49:55 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 24 Jan 2025 12:49:55 GMT
Subject: RFR: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
Message-ID: <HIIp3tkgZSwTysXtPovdZ7c9k7CoEZvBn_ISu9hUaE0=.1fc076d1-b55c-43c8-b2d0-ac91dce7c7ba@github.com>

On Tue, 21 Jan 2025 16:41:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
> 
> Thanks for the review.
> 
> Best Regards,
> -- Gouxiong

Thanks for your reviews and comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/23218#issuecomment-2612452011

From gli at openjdk.org  Fri Jan 24 12:49:56 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 24 Jan 2025 12:49:56 GMT
Subject: Integrated: 8331723: Serial: Remove the unused parameter of the method
 SerialHeap::gc_prologue
In-Reply-To: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
References: <6yiE82MZXDLiN9k0VlPNXzYnqJkdpSrLWpVVPSXb-88=.b13bebe8-12dd-47d4-9b8f-353b8df80ef6@github.com>
Message-ID: <I_DFTQhtJG0S3HNNpk2AI4QBjz2gY84_OCqYLDAOtr4=.b366c4d8-1cd6-47d6-80eb-2193d6bda756@github.com>

On Tue, 21 Jan 2025 16:41:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unnecessary parameter `full` in `SerialHeap::gc_prologue`. The previous patch is at https://github.com/openjdk/jdk/pull/19207 .
> 
> Thanks for the review.
> 
> Best Regards,
> -- Gouxiong

This pull request has now been integrated.

Changeset: c5a69b62
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5a69b620a73bb05b96b79d9d9e03cc71822862e
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8331723: Serial: Remove the unused parameter of the method SerialHeap::gc_prologue

Co-authored-by: nanxiaotao <nxtchongchong at 163.com>
Reviewed-by: ayang

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

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

From shade at openjdk.org  Fri Jan 24 12:51:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Jan 2025 12:51:48 GMT
Subject: RFR: 8348400: GenShen:
 assert(ShenandoahHeap::heap()->is_full_gc_in_progress() ||
 (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity
 #
In-Reply-To: <r7p7OKmdrNDiab6ZQZ_6S35RH2rAKG5LajSxcFl6aC4=.b7e07485-4e63-4d47-9719-6c57df391561@github.com>
References: <r7p7OKmdrNDiab6ZQZ_6S35RH2rAKG5LajSxcFl6aC4=.b7e07485-4e63-4d47-9719-6c57df391561@github.com>
Message-ID: <XArxrPz5UAyhRX6YKE2qAvSKYCzes-JWdo1TG-lSmJw=.f26ee41e-5948-4e9e-885f-4cb49cfd28f6@github.com>

On Thu, 23 Jan 2025 21:36:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When the capacity of a trashed region is transferred from the young to old generation, we must first recycle the region to break its affiliation with the young generation. Failing to do this may violate the constraint that the capacity of a generation is always equal to or greater than the capacity of its affiliated regions.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23282#pullrequestreview-2572568839

From rcastanedalo at openjdk.org  Fri Jan 24 14:17:45 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 24 Jan 2025 14:17:45 GMT
Subject: RFR: 8348562: ZGC: segmentation fault due to missing node type
 check in barrier elision analysis
In-Reply-To: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
References: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
Message-ID: <Qi_pzOKKB_LXw1ZRHb7etw2gSI0umR3G-4NXrmjfKiU=.2b8a85fa-5963-4532-b968-0f80a9c107ff@github.com>

On Fri, 24 Jan 2025 10:38:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Adding the missing node type check as described in the JBS issue. `oopptr` can be null in which case the current implementation crashes. This was only reported for JFR tests on PPC64 so far. If the expected graph pattern is not found, we bail out and skip the optimization.
> 
> `make run-test TEST="jdk/jfr" JTREG="VM_OPTIONS=-XX:+UseZGC"` has passed on linux PPC64le.

Looks good, thanks!

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

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23295#pullrequestreview-2572762310

From kdnilsen at openjdk.org  Fri Jan 24 18:35:17 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jan 2025 18:35:17 GMT
Subject: RFR: 8348595: GenShen: Fix generational free-memory no-progress check
Message-ID: <qxVLivQe7QASskJibcjSy-PmAXScg3r7k4Rdomvzws0=.03982de5-8ae8-4a9a-b940-d0990e27ff84@github.com>

At the end of a degenerated GC, we check whether sufficient progress has been made in replenishing the memory available to the mutator. The test for good progress is implemented as a ratio of free memory against the total heap size.

For generational Shenandoah, the ratio should be computed against the size of the young generation. Note that the size of the generational collection set is based on young generation size rather than total heap size.

This issue first identified in GenShen GC logs, where a large number of degenerated cycles were upgrading to full GC because the free-set progress was short of desired by 10-25%.

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

Commit messages:
 - Use freeset to determine goodness of progress
 - Use size-of young generation to assess progress

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

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

From kdnilsen at openjdk.org  Fri Jan 24 18:37:46 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jan 2025 18:37:46 GMT
Subject: RFR: 8348595: GenShen: Fix generational free-memory no-progress
 check
In-Reply-To: <qxVLivQe7QASskJibcjSy-PmAXScg3r7k4Rdomvzws0=.03982de5-8ae8-4a9a-b940-d0990e27ff84@github.com>
References: <qxVLivQe7QASskJibcjSy-PmAXScg3r7k4Rdomvzws0=.03982de5-8ae8-4a9a-b940-d0990e27ff84@github.com>
Message-ID: <tdiKxylx2bEMXQ3CQqruS1E21o8Rg-HEqCvgyeBTeBo=.9f7dfd34-737d-44e0-a4b2-6fbb56519cc0@github.com>

On Fri, 24 Jan 2025 18:30:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> At the end of a degenerated GC, we check whether sufficient progress has been made in replenishing the memory available to the mutator. The test for good progress is implemented as a ratio of free memory against the total heap size.
> 
> For generational Shenandoah, the ratio should be computed against the size of the young generation. Note that the size of the generational collection set is based on young generation size rather than total heap size.
> 
> This issue first identified in GenShen GC logs, where a large number of degenerated cycles were upgrading to full GC because the free-set progress was short of desired by 10-25%.

[netflix-calibrate-better.xlsx](https://github.com/user-attachments/files/18540252/netflix-calibrate-better.xlsx)

The attached spreadsheet provides a summary of performance benefits of this patch.  In the spreadsheet:
  Control represents tip without changes
  Better Penalty represents https://github.com/openjdk/jdk/pull/23305
  Better Progress represents https://github.com/openjdk/jdk/pull/23306 (this PR)
  Better Both represents the combined benefits of Better Penalty and Better Progress.
  
  Compared to Control, "Better Both" results are better across all measures:
  
![image](https://github.com/user-attachments/assets/849291e2-713d-4611-80ad-0c4b43aee2c5)

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

PR Comment: https://git.openjdk.org/jdk/pull/23306#issuecomment-2613155202

From kdnilsen at openjdk.org  Fri Jan 24 18:44:25 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jan 2025 18:44:25 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when not
 the fault of triggering heuristic
Message-ID: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>

Shenandoah heuristics use a penalty mechanism to cause earlier GC triggers when recent concurrent GC cycles degenerate.  Degeneration is a stop-the-world remediation that allows GC to catch up when mutator allocations fail during concurrent GC.  The fact that we needed to degenerate indicates that we were overly optimistic in delaying the trigger that starts concurrent GC.

We have observed that it is common for degenerated GC cycles to cascade upon each other.  The condition that caused an initial degenerated cycle is often not fully resolved by the end of that degenerated cycle.  For example, the application may be experiencing a phase change and the GC heuristics are not yet attuned to the new behavior.  Furthermore, a degenerated GC may exacerbate the problem condition.  During the stop-the-world pause imposed by the first degenerated GC, work continues to accumulate in the form of new client requests that are buffered in network sockets until the end of that degenerated GC.

As originally implemented, each degeneration would "pile on" additional penalties.  These penalties cause the GC frequency to continue to increase.  And the expanding CPU load of GC makes it increasingly difficult for mutator threads to catchup.  The large penalties accumulated while we are trying to resolve the problem linger long after the problem condition has been resolved.

This change does not add further to the degeneration penalties if a new degenerated cycle occurs through no fault of the triggering mechanism.  We only add the degeneration penalty if the reason we are now degenerating can be attributed to a consciously late trigger by the heuristic.

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

Commit messages:
 - Fix white space
 - Remove debug instrumentation
 - Only penalize heuristic if heuristic responsible
 - Eliminate no-fault degen penalties

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

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

From kdnilsen at openjdk.org  Fri Jan 24 18:44:25 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jan 2025 18:44:25 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when
 not the fault of triggering heuristic
In-Reply-To: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>
References: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>
Message-ID: <JVXvaRBFkXXB3VaKrSc-AJqJ2QLJobJEHLLMD1DYhOE=.67ab9622-b248-41fb-b3f4-f9cece709dbe@github.com>

On Fri, 24 Jan 2025 18:18:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Shenandoah heuristics use a penalty mechanism to cause earlier GC triggers when recent concurrent GC cycles degenerate.  Degeneration is a stop-the-world remediation that allows GC to catch up when mutator allocations fail during concurrent GC.  The fact that we needed to degenerate indicates that we were overly optimistic in delaying the trigger that starts concurrent GC.
> 
> We have observed that it is common for degenerated GC cycles to cascade upon each other.  The condition that caused an initial degenerated cycle is often not fully resolved by the end of that degenerated cycle.  For example, the application may be experiencing a phase change and the GC heuristics are not yet attuned to the new behavior.  Furthermore, a degenerated GC may exacerbate the problem condition.  During the stop-the-world pause imposed by the first degenerated GC, work continues to accumulate in the form of new client requests that are buffered in network sockets until the end of that degenerated GC.
> 
> As originally implemented, each degeneration would "pile on" additional penalties.  These penalties cause the GC frequency to continue to increase.  And the expanding CPU load of GC makes it increasingly difficult for mutator threads to catchup.  The large penalties accumulated while we are trying to resolve the problem linger long after the problem condition has been resolved.
> 
> This change does not add further to the degeneration penalties if a new degenerated cycle occurs through no fault of the triggering mechanism.  We only add the degeneration penalty if the reason we are now degenerating can be attributed to a consciously late trigger by the heuristic.

[netflix-calibrate-better.xlsx](https://github.com/user-attachments/files/18540298/netflix-calibrate-better.xlsx)

The attached spreadsheet provides a summary of performance benefits of this patch. In the spreadsheet:
Control represents tip without changes
Better Penalty represents https://github.com/openjdk/jdk/pull/23305 (this PR)
Better Progress represents https://github.com/openjdk/jdk/pull/23306
Better Both represents the combined benefits of Better Penalty and Better Progress.

Compared to Control, "Better Both" results are better across all measures:

![image](https://github.com/user-attachments/assets/522f81f5-f2ba-4ea6-a7f1-7675714fe99c)

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

PR Comment: https://git.openjdk.org/jdk/pull/23305#issuecomment-2613158108

From ysr at openjdk.org  Fri Jan 24 18:44:53 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 24 Jan 2025 18:44:53 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <52g1j3w9Wl6NwJqpJI-Im6Smp9wPb4IGtNkRpkTsPMI=.8d4cf740-4b91-4c0c-a957-b32c1d5bd85d@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
 <52g1j3w9Wl6NwJqpJI-Im6Smp9wPb4IGtNkRpkTsPMI=.8d4cf740-4b91-4c0c-a957-b32c1d5bd85d@github.com>
Message-ID: <JOeKkb7vP3-o1RhHvoPRlSPhMJ-Oz_egXkKl86iETAw=.5b3fb25c-906f-42e6-b253-4779c46e7281@github.com>

On Thu, 23 Jan 2025 18:15:16 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Filed https://bugs.openjdk.org/browse/JDK-8348420 to follow up for Shenandoah.

Thank you William!

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

PR Comment: https://git.openjdk.org/jdk/pull/22825#issuecomment-2613165189

From wkemper at openjdk.org  Fri Jan 24 19:03:48 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jan 2025 19:03:48 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when
 not the fault of triggering heuristic
In-Reply-To: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>
References: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>
Message-ID: <Tbyx8L7-bxWqTlceNset7PqvC9K0VpO6gz6miWlr9Mg=.5f4eb278-5086-4252-afcc-a91231da20fe@github.com>

On Fri, 24 Jan 2025 18:18:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Shenandoah heuristics use a penalty mechanism to cause earlier GC triggers when recent concurrent GC cycles degenerate.  Degeneration is a stop-the-world remediation that allows GC to catch up when mutator allocations fail during concurrent GC.  The fact that we needed to degenerate indicates that we were overly optimistic in delaying the trigger that starts concurrent GC.
> 
> We have observed that it is common for degenerated GC cycles to cascade upon each other.  The condition that caused an initial degenerated cycle is often not fully resolved by the end of that degenerated cycle.  For example, the application may be experiencing a phase change and the GC heuristics are not yet attuned to the new behavior.  Furthermore, a degenerated GC may exacerbate the problem condition.  During the stop-the-world pause imposed by the first degenerated GC, work continues to accumulate in the form of new client requests that are buffered in network sockets until the end of that degenerated GC.
> 
> As originally implemented, each degeneration would "pile on" additional penalties.  These penalties cause the GC frequency to continue to increase.  And the expanding CPU load of GC makes it increasingly difficult for mutator threads to catchup.  The large penalties accumulated while we are trying to resolve the problem linger long after the problem condition has been resolved.
> 
> This change does not add further to the degeneration penalties if a new degenerated cycle occurs through no fault of the triggering mechanism.  We only add the degeneration penalty if the reason we are now degenerating can be attributed to a consciously late trigger by the heuristic.

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 257:

> 255:                  byte_size_in_proper_unit(available), proper_unit_for_byte_size(available),
> 256:                  byte_size_in_proper_unit(min_threshold), proper_unit_for_byte_size(min_threshold));
> 257:     _previous_trigger_declinations = _declined_trigger_count;

This stanza of code is repeated often enough to warrant a new (protected) method in `ShenandoahHeuristics`.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 227:

> 225:          "In range before adjustment: %zd", _gc_time_penalties);
> 226: 
> 227:   if ((_previous_trigger_declinations < 16) && (step > 0)) {

Could we make this `16` be a symbolic constant?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 81:

> 79:   static const uint Moving_Average_Samples = 10; // Number of samples to store in moving averages
> 80: 
> 81:   bool _start_gc_is_pending;

A description of each of these members and how they operate in this new protocol would be helpful.

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

PR Review: https://git.openjdk.org/jdk/pull/23305#pullrequestreview-2573382758
PR Review Comment: https://git.openjdk.org/jdk/pull/23305#discussion_r1929115073
PR Review Comment: https://git.openjdk.org/jdk/pull/23305#discussion_r1929116618
PR Review Comment: https://git.openjdk.org/jdk/pull/23305#discussion_r1929117150

From ysr at openjdk.org  Fri Jan 24 22:00:46 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 24 Jan 2025 22:00:46 GMT
Subject: RFR: 8348400: GenShen:
 assert(ShenandoahHeap::heap()->is_full_gc_in_progress() ||
 (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity
 #
In-Reply-To: <r7p7OKmdrNDiab6ZQZ_6S35RH2rAKG5LajSxcFl6aC4=.b7e07485-4e63-4d47-9719-6c57df391561@github.com>
References: <r7p7OKmdrNDiab6ZQZ_6S35RH2rAKG5LajSxcFl6aC4=.b7e07485-4e63-4d47-9719-6c57df391561@github.com>
Message-ID: <cNcdf4QIvBFs_fbPF4ewqCgPTV0H9YVxslLAvrwZWfA=.57ca935d-a626-43fd-8fbc-c16799994e4c@github.com>

On Thu, 23 Jan 2025 21:36:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When the capacity of a trashed region is transferred from the young to old generation, we must first recycle the region to break its affiliation with the young generation. Failing to do this may violate the constraint that the capacity of a generation is always equal to or greater than the capacity of its affiliated regions.

Looks good (but seemed tricky to reason about; I left some comments questions, but these are more for me to understand the full context of state transitions than as a formal review necessarily).

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1300:

> 1298:   if (!transferred) {
> 1299:     log_warning(gc, free)("Forcing transfer of %zu to old reserve.", idx);
> 1300:     if (r->is_trash() && r->is_young()) {

I see that you don't unnecessarily want to recycle eagerly here unless the transfer attempt fails (which it could for one of several reasons).

But can you share the disadvantage of always checking if the region is trash and recycling eagerly first? I can see that eager check and recycling unnecessarily slows down this path which can make the evacuation path slightly more heavyweight sometimes.

I also noticed that the allocation paths allow for the region being fresh trash that is unrecycled and therefore would try the recycle regardless, so this does look like it's being done only to satisfy the size invariant checks, and not to get any more efficiency from skipping the recycle.

Could recycling of trash be happening concurrently such that our skipping it here can sometimes make things faster because it's been done by the time we start allocating into it?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23282#pullrequestreview-2573651629
PR Review Comment: https://git.openjdk.org/jdk/pull/23282#discussion_r1929278125

From wkemper at openjdk.org  Fri Jan 24 22:02:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jan 2025 22:02:21 GMT
Subject: RFR: 8348420: Shenandoah: Check is_reserved before using ReservedSpace
 instances
Message-ID: <9kahEGS14dztezNFoP1H7ETJJXwwurLcldaBQ5NOaYg=.0079d577-1269-4c2c-b84e-a9e2676d083d@github.com>

Follow up on [JDK-8346572](https://bugs.openjdk.org/browse/JDK-8346572) for Shenandoah.

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

Commit messages:
 - Exit during initialization if required memory cannot be reserved

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

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

From ysr at openjdk.org  Fri Jan 24 22:36:45 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 24 Jan 2025 22:36:45 GMT
Subject: RFR: 8348420: Shenandoah: Check is_reserved before using
 ReservedSpace instances
In-Reply-To: <9kahEGS14dztezNFoP1H7ETJJXwwurLcldaBQ5NOaYg=.0079d577-1269-4c2c-b84e-a9e2676d083d@github.com>
References: <9kahEGS14dztezNFoP1H7ETJJXwwurLcldaBQ5NOaYg=.0079d577-1269-4c2c-b84e-a9e2676d083d@github.com>
Message-ID: <T7y6OkaVP5a2H_D9zc2g15sNCLFDwQYIHPpuN0ljbtM=.f33113c1-6c38-4c7b-b877-8287058f88ee@github.com>

On Fri, 24 Jan 2025 21:55:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Follow up on [JDK-8346572](https://bugs.openjdk.org/browse/JDK-8346572) for Shenandoah.

LGTM! ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23308#pullrequestreview-2573714199

From wkemper at openjdk.org  Fri Jan 24 23:37:49 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jan 2025 23:37:49 GMT
Subject: Integrated: 8348420: Shenandoah: Check is_reserved before using
 ReservedSpace instances
In-Reply-To: <9kahEGS14dztezNFoP1H7ETJJXwwurLcldaBQ5NOaYg=.0079d577-1269-4c2c-b84e-a9e2676d083d@github.com>
References: <9kahEGS14dztezNFoP1H7ETJJXwwurLcldaBQ5NOaYg=.0079d577-1269-4c2c-b84e-a9e2676d083d@github.com>
Message-ID: <wKh3oQTaRf6_fk7YGXMojV1jgNa52YwexWRWMvGS0Ss=.7879a753-cfbd-44e3-8463-153ae650ef07@github.com>

On Fri, 24 Jan 2025 21:55:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Follow up on [JDK-8346572](https://bugs.openjdk.org/browse/JDK-8346572) for Shenandoah.

This pull request has now been integrated.

Changeset: 7c0985fc
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c0985fc32ec5419f7b409248385c5ca80f1093f
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8348420: Shenandoah: Check is_reserved before using ReservedSpace instances

Reviewed-by: ysr

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

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

From zgu at openjdk.org  Sat Jan 25 21:23:35 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sat, 25 Jan 2025 21:23:35 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v6]
In-Reply-To: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
Message-ID: <k7xeGByZHN9-OG83aTQzU5OFM3aNuu6u8lXsoJAp36U=.b291cb28-31f3-4d76-9349-298ec9af7598@github.com>

> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
> 
> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  More cleanup based on Yang's comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21089/files
  - new: https://git.openjdk.org/jdk/pull/21089/files/332c1cdd..20b036a1

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

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

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

From zgu at openjdk.org  Sat Jan 25 21:23:40 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sat, 25 Jan 2025 21:23:40 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v5]
In-Reply-To: <rbsVqQ47lPQ7ieH1qU3MqFn74Hs0Ma351-_1IZlMLMk=.e98eb360-92a6-491a-ad81-60094f43e685@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
 <jw2JO1tRma8p58ImXboM86u5hTywVURMcnK-GaH9sbg=.95a74a5c-1fc1-40cd-83fd-8952366df600@github.com>
 <rbsVqQ47lPQ7ieH1qU3MqFn74Hs0Ma351-_1IZlMLMk=.e98eb360-92a6-491a-ad81-60094f43e685@github.com>
Message-ID: <0K_tLERk-hJm1ZGAPSWX7hhEMj8VWBD4A8ihRzbbUxc=.599c8e06-305b-4b35-b056-a715a4d0a6af@github.com>

On Wed, 22 Jan 2025 11:11:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Zhengyu Gu 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 17 additional commits since the last revision:
>> 
>>  - Yang's comment
>>  - Merge branch 'master' into JDK-8339668
>>  - Adopt latest PartialArrayStats changes
>>  - Merge branch 'master' into JDK-8339668
>>  - Merge branch 'master' into JDK-8339668
>>  - @tschatzl's ScannerTask changes
>>  - @tschatzl's comment
>>  - v8
>>  - v7
>>  - v6
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/7a117f9d...332c1cdd
>
> src/hotspot/share/gc/parallel/psCompactionManager.cpp line 43:
> 
>> 41: #include "oops/objArrayKlass.inline.hpp"
>> 42: #include "oops/oop.inline.hpp"
>> 43: #include "utilities/checkedCast.hpp"
> 
> Can this be removed now?

Done.

> src/hotspot/share/gc/parallel/psCompactionManager.cpp line 61:
> 
>> 59: ParCompactionManager::ParCompactionManager(PreservedMarks* preserved_marks,
>> 60:                                            ReferenceProcessor* ref_processor)
>> 61:   :_partial_array_splitter(_partial_array_state_manager, ParallelScavengeHeap::heap()->workers().max_workers()),
> 
> I would probably pass `parallel_gc_threads` into the constructor of `ParCompactionManager`, instead of calling `max_workers()` directly here, in order to maintain a single source of truth. YMMV.

Fixed

> src/hotspot/share/gc/parallel/psCompactionManager.cpp line 128:
> 
>> 126:   size_t array_length = obj_array->length();
>> 127:   size_t initial_chunk_size =
>> 128:     // The destination array is unused when processing states.
> 
> This comment is not very helpful; I had to look into the callee to find out it's referring to `nullptr` in the args and why one can use `nullptr` here, but that process is fairly straightforward, so this comment can probably be dropped.

Fixed

> src/hotspot/share/gc/shared/taskqueue.hpp line 566:
> 
>> 564: // Discriminated union over oop/oop*, narrowOop*, and PartialArrayState.
>> 565: // Uses a low tag in the associated pointer to identify the category.
>> 566: // Oop/oop* are overloaded using the same tag because they can not appear at the
> 
> The reason why "they can not appear at the same time" is that one is for young-gc and the other full-gc, right? If so, maybe state that explicitly.

As far as Parallel, `PromotionManager` uses `ScannerTask` to wrap around `*oop` and `CompactionManager` to wrap around `oop`, which is true. But I don't think it has to have such correlation. 

Probably should phase as `ScannerTask` wraps `*oop` or `oop` using the same tag, because they cannot be mixed in the same queue. 

What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1929611411
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1929611365
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1929611400
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1929611054

From kdnilsen at openjdk.org  Sun Jan 26 23:38:56 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 26 Jan 2025 23:38:56 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when
 not the fault of triggering heuristic
In-Reply-To: <Tbyx8L7-bxWqTlceNset7PqvC9K0VpO6gz6miWlr9Mg=.5f4eb278-5086-4252-afcc-a91231da20fe@github.com>
References: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>
 <Tbyx8L7-bxWqTlceNset7PqvC9K0VpO6gz6miWlr9Mg=.5f4eb278-5086-4252-afcc-a91231da20fe@github.com>
Message-ID: <KaF0_87zqf4Ug1OtUtbwCT4f7y0wCs2o8DY-JGtd16g=.97de548a-8714-4d58-8651-68cc520cca9b@github.com>

On Fri, 24 Jan 2025 18:58:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah heuristics use a penalty mechanism to cause earlier GC triggers when recent concurrent GC cycles degenerate.  Degeneration is a stop-the-world remediation that allows GC to catch up when mutator allocations fail during concurrent GC.  The fact that we needed to degenerate indicates that we were overly optimistic in delaying the trigger that starts concurrent GC.
>> 
>> We have observed that it is common for degenerated GC cycles to cascade upon each other.  The condition that caused an initial degenerated cycle is often not fully resolved by the end of that degenerated cycle.  For example, the application may be experiencing a phase change and the GC heuristics are not yet attuned to the new behavior.  Furthermore, a degenerated GC may exacerbate the problem condition.  During the stop-the-world pause imposed by the first degenerated GC, work continues to accumulate in the form of new client requests that are buffered in network sockets until the end of that degenerated GC.
>> 
>> As originally implemented, each degeneration would "pile on" additional penalties.  These penalties cause the GC frequency to continue to increase.  And the expanding CPU load of GC makes it increasingly difficult for mutator threads to catchup.  The large penalties accumulated while we are trying to resolve the problem linger long after the problem condition has been resolved.
>> 
>> This change does not add further to the degeneration penalties if a new degenerated cycle occurs through no fault of the triggering mechanism.  We only add the degeneration penalty if the reason we are now degenerating can be attributed to a consciously late trigger by the heuristic.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 257:
> 
>> 255:                  byte_size_in_proper_unit(available), proper_unit_for_byte_size(available),
>> 256:                  byte_size_in_proper_unit(min_threshold), proper_unit_for_byte_size(min_threshold));
>> 257:     _previous_trigger_declinations = _declined_trigger_count;
> 
> This stanza of code is repeated often enough to warrant a new (protected) method in `ShenandoahHeuristics`.

Thanks for your review.  I've encapsulated this code into "accept_trigger()".

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 227:
> 
>> 225:          "In range before adjustment: %zd", _gc_time_penalties);
>> 226: 
>> 227:   if ((_previous_trigger_declinations < 16) && (step > 0)) {
> 
> Could we make this `16` be a symbolic constant?

Thanks.  Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23305#discussion_r1929894461
PR Review Comment: https://git.openjdk.org/jdk/pull/23305#discussion_r1929894482

From kdnilsen at openjdk.org  Mon Jan 27 00:01:48 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 27 Jan 2025 00:01:48 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when
 not the fault of triggering heuristic
In-Reply-To: <Tbyx8L7-bxWqTlceNset7PqvC9K0VpO6gz6miWlr9Mg=.5f4eb278-5086-4252-afcc-a91231da20fe@github.com>
References: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>
 <Tbyx8L7-bxWqTlceNset7PqvC9K0VpO6gz6miWlr9Mg=.5f4eb278-5086-4252-afcc-a91231da20fe@github.com>
Message-ID: <Cr6x_XZUtomDZo0WNsFvLONmBiuOB7EB4fsoZYRZ83g=.5f00d10e-409b-4312-a8e2-8e7cb2511e02@github.com>

On Fri, 24 Jan 2025 19:00:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Shenandoah heuristics use a penalty mechanism to cause earlier GC triggers when recent concurrent GC cycles degenerate.  Degeneration is a stop-the-world remediation that allows GC to catch up when mutator allocations fail during concurrent GC.  The fact that we needed to degenerate indicates that we were overly optimistic in delaying the trigger that starts concurrent GC.
>> 
>> We have observed that it is common for degenerated GC cycles to cascade upon each other.  The condition that caused an initial degenerated cycle is often not fully resolved by the end of that degenerated cycle.  For example, the application may be experiencing a phase change and the GC heuristics are not yet attuned to the new behavior.  Furthermore, a degenerated GC may exacerbate the problem condition.  During the stop-the-world pause imposed by the first degenerated GC, work continues to accumulate in the form of new client requests that are buffered in network sockets until the end of that degenerated GC.
>> 
>> As originally implemented, each degeneration would "pile on" additional penalties.  These penalties cause the GC frequency to continue to increase.  And the expanding CPU load of GC makes it increasingly difficult for mutator threads to catchup.  The large penalties accumulated while we are trying to resolve the problem linger long after the problem condition has been resolved.
>> 
>> This change does not add further to the degeneration penalties if a new degenerated cycle occurs through no fault of the triggering mechanism.  We only add the degeneration penalty if the reason we are now degenerating can be attributed to a consciously late trigger by the heuristic.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 81:
> 
>> 79:   static const uint Moving_Average_Samples = 10; // Number of samples to store in moving averages
>> 80: 
>> 81:   bool _start_gc_is_pending;
> 
> A description of each of these members and how they operate in this new protocol would be helpful.

I've added descriptions.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23305#discussion_r1929897784

From kdnilsen at openjdk.org  Mon Jan 27 02:05:02 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 27 Jan 2025 02:05:02 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when
 not the fault of triggering heuristic [v2]
In-Reply-To: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>
References: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>
Message-ID: <IHu0084TdPHzsXBBxYqfGcmur84YSZe87_IoJ_ppCC4=.80f116b2-6589-45ea-8e25-e75409d03d6e@github.com>

> Shenandoah heuristics use a penalty mechanism to cause earlier GC triggers when recent concurrent GC cycles degenerate.  Degeneration is a stop-the-world remediation that allows GC to catch up when mutator allocations fail during concurrent GC.  The fact that we needed to degenerate indicates that we were overly optimistic in delaying the trigger that starts concurrent GC.
> 
> We have observed that it is common for degenerated GC cycles to cascade upon each other.  The condition that caused an initial degenerated cycle is often not fully resolved by the end of that degenerated cycle.  For example, the application may be experiencing a phase change and the GC heuristics are not yet attuned to the new behavior.  Furthermore, a degenerated GC may exacerbate the problem condition.  During the stop-the-world pause imposed by the first degenerated GC, work continues to accumulate in the form of new client requests that are buffered in network sockets until the end of that degenerated GC.
> 
> As originally implemented, each degeneration would "pile on" additional penalties.  These penalties cause the GC frequency to continue to increase.  And the expanding CPU load of GC makes it increasingly difficult for mutator threads to catchup.  The large penalties accumulated while we are trying to resolve the problem linger long after the problem condition has been resolved.
> 
> This change does not add further to the degeneration penalties if a new degenerated cycle occurs through no fault of the triggering mechanism.  We only add the degeneration penalty if the reason we are now degenerating can be attributed to a consciously late trigger by the heuristic.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Respond to reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23305/files
  - new: https://git.openjdk.org/jdk/pull/23305/files/520dd03e..ee3cdacc

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

  Stats: 73 lines in 9 files changed: 26 ins; 26 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/23305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23305/head:pull/23305

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

From rrich at openjdk.org  Mon Jan 27 07:01:46 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 27 Jan 2025 07:01:46 GMT
Subject: RFR: 8348562: ZGC: segmentation fault due to missing node type
 check in barrier elision analysis
In-Reply-To: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
References: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
Message-ID: <JypkxjHMebZ85hui6qgubCtM8qNATur8eVzDNZRll6Y=.4327ff28-3dbf-4322-b34d-6b05bf685747@github.com>

On Fri, 24 Jan 2025 10:38:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Adding the missing node type check as described in the JBS issue. `oopptr` can be null in which case the current implementation crashes. This was only reported for JFR tests on PPC64 so far. If the expected graph pattern is not found, we bail out and skip the optimization.
> 
> `make run-test TEST="jdk/jfr" JTREG="VM_OPTIONS=-XX:+UseZGC"` has passed on linux PPC64le.

> ```
> V  [libjvm.so+0xa1a3f0]  TypePtr::offset() const+0x14  (type.hpp:994)
> V  [libjvm.so+0x1d35288]  get_base_and_offset(MachNode const*, long&)+0xb0  (zBarrierSetC2.cpp:557)
> V  [libjvm.so+0x1d35818]  is_allocation(Node const*)+0x108  (zBarrierSetC2.cpp:629)
> ```

`is_allocation` is looking for a memory reference where `base` is `Op_ThreadLocal`. @TheRealMDoerr would you mind reproducing the crash with a little bit of tracing that dumps `base` just before the crash? S.th. like `base->dump(3) ; base->dump(-3);` I guess it is pretty unlikely but I'd like to make sure that we don't miss an actual allocation because the pattern is a little bit different on ppc.

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

PR Comment: https://git.openjdk.org/jdk/pull/23295#issuecomment-2614975747

From rcastanedalo at openjdk.org  Mon Jan 27 09:10:55 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 27 Jan 2025 09:10:55 GMT
Subject: RFR: 8348562: ZGC: segmentation fault due to missing node type
 check in barrier elision analysis
In-Reply-To: <JypkxjHMebZ85hui6qgubCtM8qNATur8eVzDNZRll6Y=.4327ff28-3dbf-4322-b34d-6b05bf685747@github.com>
References: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
 <JypkxjHMebZ85hui6qgubCtM8qNATur8eVzDNZRll6Y=.4327ff28-3dbf-4322-b34d-6b05bf685747@github.com>
Message-ID: <vsw0XAjAI2frjAtAyehLJVk6mSIkp-UECbXs2WUHBCw=.32c883cf-5aae-445c-9fa9-0ebdc39b22bc@github.com>

On Mon, 27 Jan 2025 06:59:34 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I guess it is pretty unlikely but I'd like to make sure that we don't miss an actual allocation because the pattern is a little bit different on ppc.

Hi Richard, note that  `compiler/gcbarriers/TestG1BarrierGeneration.java` passes on PPC64 after applying [JDK-8346280](https://bugs.openjdk.org/browse/JDK-8346280) ([under review](https://github.com/openjdk/jdk/pull/23235)), implying that `is_allocation` is successful on PPC64 at least for the most common allocation scenarios.
I also tried running the optimization tests in `compiler/gcbarriers/TestZGCBarrierElision.java` (currently only enabled for x64 and aarch64) on PPC64, and test cases that rely on `is_allocation` finding an allocation (such as `testAllocateThenStore`) pass. There are some failures, but I suspect they are due to other factors (e.g. ADL instruction naming mismatches). If you want to study the effectiveness of the barrier elision optimization on PPC64, I suggest to address these failures and enable `compiler/gcbarriers/TestZGCBarrierElision.java` for PPC64 as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/23295#issuecomment-2615195440

From rrich at openjdk.org  Mon Jan 27 10:00:50 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 27 Jan 2025 10:00:50 GMT
Subject: RFR: 8348562: ZGC: segmentation fault due to missing node type
 check in barrier elision analysis
In-Reply-To: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
References: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
Message-ID: <x9-HsxelwbSlvcpj5YXoh2B4Uriou1NXVDl24ESvV2I=.2e59c37f-3b0a-481d-b06a-5ca084f2365a@github.com>

On Fri, 24 Jan 2025 10:38:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Adding the missing node type check as described in the JBS issue. `oopptr` can be null in which case the current implementation crashes. This was only reported for JFR tests on PPC64 so far. If the expected graph pattern is not found, we bail out and skip the optimization.
> 
> `make run-test TEST="jdk/jfr" JTREG="VM_OPTIONS=-XX:+UseZGC"` has passed on linux PPC64le.

Looks reasonable.
Thanks for fixing!
Richard.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23295#pullrequestreview-2574983849

From rrich at openjdk.org  Mon Jan 27 10:00:51 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 27 Jan 2025 10:00:51 GMT
Subject: RFR: 8348562: ZGC: segmentation fault due to missing node type
 check in barrier elision analysis
In-Reply-To: <vsw0XAjAI2frjAtAyehLJVk6mSIkp-UECbXs2WUHBCw=.32c883cf-5aae-445c-9fa9-0ebdc39b22bc@github.com>
References: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
 <JypkxjHMebZ85hui6qgubCtM8qNATur8eVzDNZRll6Y=.4327ff28-3dbf-4322-b34d-6b05bf685747@github.com>
 <vsw0XAjAI2frjAtAyehLJVk6mSIkp-UECbXs2WUHBCw=.32c883cf-5aae-445c-9fa9-0ebdc39b22bc@github.com>
Message-ID: <r1DHnjOkYhL7xVWAsgDAOLx7FusBbt9F8jaaRvNp6DY=.b8c03df2-e593-4dc2-8398-7561da956078@github.com>

On Mon, 27 Jan 2025 09:08:07 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> > I guess it is pretty unlikely but I'd like to make sure that we don't miss an actual allocation because the pattern is a little bit different on ppc.
> 
> Hi Richard, note that `compiler/gcbarriers/TestG1BarrierGeneration.java` passes on PPC64 after applying [JDK-8346280](https://bugs.openjdk.org/browse/JDK-8346280) ([under review](https://github.com/openjdk/jdk/pull/23235)), implying that `is_allocation` is successful on PPC64 at least for the most common allocation scenarios. I also tried running the optimization tests in `compiler/gcbarriers/TestZGCBarrierElision.java` (currently only enabled for x64 and aarch64) on PPC64, and test cases that rely on `is_allocation` finding an allocation (such as `testAllocateThenStore`) pass. There are some failures, but I suspect they are due to other factors (e.g. ADL instruction naming mismatches). If you want to study the effectiveness of the barrier elision optimization on PPC64, I suggest to address these failures and enable `compiler/gcbarriers/TestZGCBarrierElision.java` for PPC64 as well.

Thanks for the explanation, Roberto. I wasn't aware that the code is trying to elide barriers and therefore missing one isn't that severe. Martin said he'll file an RFE to analyze the effectiveness on PPC64. I'm ok with that.

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

PR Comment: https://git.openjdk.org/jdk/pull/23295#issuecomment-2615300955

From mdoerr at openjdk.org  Mon Jan 27 10:15:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 27 Jan 2025 10:15:50 GMT
Subject: RFR: 8348562: ZGC: segmentation fault due to missing node type
 check in barrier elision analysis
In-Reply-To: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
References: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
Message-ID: <yWsaiIYbMPjDt4Kn-CoYfN8Jz55qTBNUXCxBPpGi5Uo=.b23f919f-7214-42af-abc9-332dde87e00a@github.com>

On Fri, 24 Jan 2025 10:38:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Adding the missing node type check as described in the JBS issue. `oopptr` can be null in which case the current implementation crashes. This was only reported for JFR tests on PPC64 so far. If the expected graph pattern is not found, we bail out and skip the optimization.
> 
> `make run-test TEST="jdk/jfr" JTREG="VM_OPTIONS=-XX:+UseZGC"` has passed on linux PPC64le.

Thanks for the reviews! I've filed [JDK-8348656](https://bugs.openjdk.org/browse/JDK-8348656). It probably makes sense to take a closer look when somebody has time for such enhancements.

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

PR Comment: https://git.openjdk.org/jdk/pull/23295#issuecomment-2615332835

From mdoerr at openjdk.org  Mon Jan 27 10:15:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 27 Jan 2025 10:15:50 GMT
Subject: Integrated: 8348562: ZGC: segmentation fault due to missing node type
 check in barrier elision analysis
In-Reply-To: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
References: <xB5PF6OL_l_qlLVZkNxDEKTSOWDT2MK30Dbu1_a4HGk=.d94728e6-0258-4506-a04c-a409ef62a039@github.com>
Message-ID: <4bcfm8n3L0biLRB__Of8zhR8Wr-UHhqJLL_uftUW1IY=.9edc8139-32c6-4b13-b65f-4074f3025785@github.com>

On Fri, 24 Jan 2025 10:38:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Adding the missing node type check as described in the JBS issue. `oopptr` can be null in which case the current implementation crashes. This was only reported for JFR tests on PPC64 so far. If the expected graph pattern is not found, we bail out and skip the optimization.
> 
> `make run-test TEST="jdk/jfr" JTREG="VM_OPTIONS=-XX:+UseZGC"` has passed on linux PPC64le.

This pull request has now been integrated.

Changeset: afcc2b03
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/afcc2b03afc77f730300e1d92471466d56ed75fb
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8348562: ZGC: segmentation fault due to missing node type check in barrier elision analysis

Reviewed-by: rcastanedalo, rrich

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

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

From tschatzl at openjdk.org  Mon Jan 27 10:24:51 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 27 Jan 2025 10:24:51 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full [v2]
In-Reply-To: <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
 <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
Message-ID: <bj_PCVM_KqMi_VQh5qCiovGuH08wIAXDU6I90jk-x3M=.7a305f35-bf48-4aec-9ae7-d2abd74b0ee9@github.com>

On Fri, 24 Jan 2025 11:14:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR restores the support for allocation in old-gen when heap is almost full, detected as non-empty young-gen after full gc, which was removed by mistake in [JDK-8333786](https://bugs.openjdk.org/browse/JDK-8333786). With this change, the benchmark attached to the ticket now completes in ~13 GC.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23270#pullrequestreview-2575039796

From ayang at openjdk.org  Mon Jan 27 12:33:48 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Jan 2025 12:33:48 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v6]
In-Reply-To: <k7xeGByZHN9-OG83aTQzU5OFM3aNuu6u8lXsoJAp36U=.b291cb28-31f3-4d76-9349-298ec9af7598@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
 <k7xeGByZHN9-OG83aTQzU5OFM3aNuu6u8lXsoJAp36U=.b291cb28-31f3-4d76-9349-298ec9af7598@github.com>
Message-ID: <8nQGP6N8KzZyAfAFdC0pKPOcAirxVd22DicrZHCT0Uc=.2bd228af-8f9f-445e-adbf-76afaa3f5cdc@github.com>

On Sat, 25 Jan 2025 21:23:35 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
>> 
>> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup based on Yang's comment

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21089#pullrequestreview-2575312094

From ayang at openjdk.org  Mon Jan 27 12:33:48 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Jan 2025 12:33:48 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v5]
In-Reply-To: <0K_tLERk-hJm1ZGAPSWX7hhEMj8VWBD4A8ihRzbbUxc=.599c8e06-305b-4b35-b056-a715a4d0a6af@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
 <jw2JO1tRma8p58ImXboM86u5hTywVURMcnK-GaH9sbg=.95a74a5c-1fc1-40cd-83fd-8952366df600@github.com>
 <rbsVqQ47lPQ7ieH1qU3MqFn74Hs0Ma351-_1IZlMLMk=.e98eb360-92a6-491a-ad81-60094f43e685@github.com>
 <0K_tLERk-hJm1ZGAPSWX7hhEMj8VWBD4A8ihRzbbUxc=.599c8e06-305b-4b35-b056-a715a4d0a6af@github.com>
Message-ID: <_gsxVISZg_XgkdI3mIun4eeE2bcpGr99aAAQFYtXXk4=.ab01513d-50e7-479d-a4d4-66475e02b477@github.com>

On Sat, 25 Jan 2025 21:17:39 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> But I don't think it has to have such correlation.

I believe this is due to the choice of diff gc-algorithms. Young-gc uses scavenging (copying), while full-gc uses mark-compact (lisp-2). The former performs "pointer remap" in the same phase as forwarding.

(Ofc, this is just for comment/doc. Feel free to keep as is, or revise, or maybe other reviewers have sth to share.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1930453695

From rcastanedalo at openjdk.org  Mon Jan 27 14:06:30 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 27 Jan 2025 14:06:30 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v2]
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

Roberto Casta?eda Lozano 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 commit 'afcc2b0' into JDK-8346280-late-barrier-elision
 - Add new test case (store after exception)
 - Remove unused includes
 - Remove temporary UseNewCode guard
 - Use clearer names and document access API interface
 - Move ZGC-specific barrier elision code to BarrierSetC2
 - Set UseNewCode to true temporarily
 - Make elide_mach_barrier virtual
 - Move late barrier elision analysis from G1BarrierSetC2 to BarrierSetC2
 - Initial implementation
 - ... and 1 more: https://git.openjdk.org/jdk/compare/afcc2b03...ab47d7f8

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

Changes: https://git.openjdk.org/jdk/pull/23235/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23235&range=01
  Stats: 777 lines in 9 files changed: 494 ins; 264 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23235/head:pull/23235

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

From rcastanedalo at openjdk.org  Mon Jan 27 14:13:48 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 27 Jan 2025 14:13:48 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1
In-Reply-To: <wHpelszhSw8AcnxWcX1xcNlstYSmParNGirOnsXrRIE=.a2ef1520-5860-4635-8385-f8314e02166b@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <wHpelszhSw8AcnxWcX1xcNlstYSmParNGirOnsXrRIE=.a2ef1520-5860-4635-8385-f8314e02166b@github.com>
Message-ID: <zcfZQplCqMczBXGiFa3tvFHkbBx9H_B1S6-T50020Po=.44bd2d90-f45c-4ee4-8218-d84fbf1f97a8@github.com>

On Fri, 24 Jan 2025 10:40:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
>> 
>> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
>> 
>> 
>> o = new MyObject();
>> if (...) {
>>     o.myField = ...;  // barrier elided only after this changeset
>>                       // (assuming no safepoint in the if condition)
>> }
>> 
>> 
>> or in initialization writes placed after exception-throwing checks:
>> 
>> 
>> o = new MyObject();
>> if (...) {
>>     throw new Exception("");
>> }
>> o.myField = ...;  // barrier elided only after this changeset
>>                   // (assuming no safepoint in the above if condition)
>> 
>> 
>> These patterns are commonly found in Java code, e.g. in the core libraries:
>> 
>> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
>> 
>> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
>> 
>> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
>> 
>> 
>> Object[] a = new Object[...];
>> for (int i = 0; i < a.length; i++) {
>>     a[i] = ...;  // barrier elided only after this changeset
>> }
>> 
>> 
>> or eliding barriers from array initialization writes with unknown array index:
>> 
>> 
>> Object[] a = new Object[...];
>> a[index] = ...;  // barrier elided only after this changeset
>> 
>> 
>> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_inde...
>
> I agree with your suggestion. I've created https://github.com/openjdk/jdk/pull/23295. Thanks!

I just updated this changeset to include the fix to [JDK-8348562](https://bugs.openjdk.org/browse/JDK-8348562), moved here from `zBarrierSetC2.cpp` to `barrierSetC2.cpp`. @TheRealMDoerr please let me know if you find any other failures on PPC64 -- and also feel free to review this changeset ;)

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2615867292

From gli at openjdk.org  Mon Jan 27 14:55:47 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 27 Jan 2025 14:55:47 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full [v2]
In-Reply-To: <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
 <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
Message-ID: <lCj84dNL22pwvLEE4yDvM8EPu3tkICtPefTtSHJU2W4=.ee7c9da6-242b-4bf5-9e1b-6480b1f40d6f@github.com>

On Fri, 24 Jan 2025 11:14:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR restores the support for allocation in old-gen when heap is almost full, detected as non-empty young-gen after full gc, which was removed by mistake in [JDK-8333786](https://bugs.openjdk.org/browse/JDK-8333786). With this change, the benchmark attached to the ticket now completes in ~13 GC.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good.

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

Marked as reviewed by gli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23270#pullrequestreview-2575662105

From aboldtch at openjdk.org  Mon Jan 27 15:00:51 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 27 Jan 2025 15:00:51 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full [v2]
In-Reply-To: <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
 <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
Message-ID: <5yhQ84Fzbn7O21cWYNDWXL9M1tbEO6-CLacA85-ODio=.b1fcd52e-bdad-43d3-b1b6-d205b6a461e1@github.com>

On Fri, 24 Jan 2025 11:14:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR restores the support for allocation in old-gen when heap is almost full, detected as non-empty young-gen after full gc, which was removed by mistake in [JDK-8333786](https://bugs.openjdk.org/browse/JDK-8333786). With this change, the benchmark attached to the ticket now completes in ~13 GC.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Parallel has the same problem right?

It feels like we are throwing OOM to late. When we have a promotion failure and the following full fails to evacuate eden, maybe we should just bail rather than allocating in old. 

I played around with something like this. Obviously not OK as it does not clear soft refs etc. But I think it is worth discussing if we should be so free with allocating new objects directly in the old generation.

diff --git a/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp b/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
index 6b1b25dd6aa..d0152aa1a99 100644
--- a/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
+++ b/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
@@ -452,10 +452,15 @@ HeapWord* ParallelScavengeHeap::satisfy_failed_allocation(size_t size, bool is_t
     return expand_heap_and_allocate(size, is_tlab);
   }
 
+  const unsigned tfc = total_full_collections();
   // If young-gen can handle this allocation, attempt young-gc firstly.
   bool should_run_young_gc = is_tlab || should_alloc_in_eden(size);
   collect_at_safepoint(!should_run_young_gc);
 
+  if (UseNewCode && should_run_young_gc && tfc != total_full_collections() && !young_gen()->eden_space()->is_empty()) {
+    return nullptr;
+  }
+
   result = expand_heap_and_allocate(size, is_tlab);
   if (result != nullptr) {
     return result;
diff --git a/src/hotspot/share/gc/serial/serialHeap.cpp b/src/hotspot/share/gc/serial/serialHeap.cpp
index 23f1df6fc66..62f9d877404 100644
--- a/src/hotspot/share/gc/serial/serialHeap.cpp
+++ b/src/hotspot/share/gc/serial/serialHeap.cpp
@@ -529,10 +529,16 @@ HeapWord* SerialHeap::satisfy_failed_allocation(size_t size, bool is_tlab) {
     return result;   // Could be null if we are out of space.
   }
 
+  const unsigned tfc = total_full_collections();
+
   // If young-gen can handle this allocation, attempt young-gc firstly.
   bool should_run_young_gc = _young_gen->should_allocate(size, is_tlab);
   collect_at_safepoint(!should_run_young_gc);
 
+  if (UseNewCode && should_run_young_gc && tfc != total_full_collections() && !young_gen()->eden()->is_empty()) {
+    return nullptr;
+  }
+
   result = attempt_allocation(size, is_tlab, false /*first_only*/);
   if (result != nullptr) {
     return result;

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

PR Review: https://git.openjdk.org/jdk/pull/23270#pullrequestreview-2575676583

From ayang at openjdk.org  Mon Jan 27 15:00:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Jan 2025 15:00:52 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full [v2]
In-Reply-To: <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
 <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
Message-ID: <VWB0YYz-0cIFk556WYTd6mePnS3D5dOpDH89yeXcVd4=.6dd78839-0f00-4aba-bd0d-c9a74383686b@github.com>

On Fri, 24 Jan 2025 11:14:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR restores the support for allocation in old-gen when heap is almost full, detected as non-empty young-gen after full gc, which was removed by mistake in [JDK-8333786](https://bugs.openjdk.org/browse/JDK-8333786). With this change, the benchmark attached to the ticket now completes in ~13 GC.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23270#issuecomment-2615985690

From ayang at openjdk.org  Mon Jan 27 15:00:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Jan 2025 15:00:53 GMT
Subject: Integrated: 8346920: Serial: Support allocation in old generation when
 heap is almost full
In-Reply-To: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
Message-ID: <S0tVLsD-OY_1Dh3MVyFQr5NP_iblu-NSfvrrYxDcQ3U=.648a1977-4dd3-4dde-a89e-56191c88cfa5@github.com>

On Thu, 23 Jan 2025 15:12:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR restores the support for allocation in old-gen when heap is almost full, detected as non-empty young-gen after full gc, which was removed by mistake in [JDK-8333786](https://bugs.openjdk.org/browse/JDK-8333786). With this change, the benchmark attached to the ticket now completes in ~13 GC.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: ad01dfb6
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad01dfb670215a35d4151c7129c9086888e1f9e8
Stats:     26 lines in 2 files changed: 22 ins; 2 del; 2 mod

8346920: Serial: Support allocation in old generation when heap is almost full

Reviewed-by: tschatzl, gli, sjohanss

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

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

From ayang at openjdk.org  Mon Jan 27 15:28:51 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Jan 2025 15:28:51 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full [v2]
In-Reply-To: <5yhQ84Fzbn7O21cWYNDWXL9M1tbEO6-CLacA85-ODio=.b1fcd52e-bdad-43d3-b1b6-d205b6a461e1@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
 <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
 <5yhQ84Fzbn7O21cWYNDWXL9M1tbEO6-CLacA85-ODio=.b1fcd52e-bdad-43d3-b1b6-d205b6a461e1@github.com>
Message-ID: <HT8p0uMZjQTaQ8fVBcgaFb-8aEUdj0KJ56uV7NVSCZA=.12867620-7a81-4dbb-9a06-b239c28124cd@github.com>

On Mon, 27 Jan 2025 14:58:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Parallel has the same problem right?

Parallel also has the problem of fragmentation, where a single large obj in the beginning of eden can cause a large hole in the end of old-gen, because objs can't cross generation boundary.

Parallel doesn't have the problem of running >1000 GCs before exit, captured by the attached bm, because Parallel implements `UseGCOverheadLimit`. (For this particular bm with the selected heap-size, this problematic scenario doesn't occur for Parallel. One can even dodge this problematic scenario in Serial by using a diff heap-size, e.g. 200m instead of 100m.)

This PR mitigates the fragmentation problem to some extent, and it solves the many-gc-before-exit problem.

> When we have a promotion failure and the following full fails to evacuate eden, maybe we should just bail rather than allocating in old.

That's another way to address the many-gc-before-exit problem. However, end users may get surprised with this "premature" OOM when heap still has a sizable margin till 100%. (Ofc, this is pure speculation.)

I believe the newly introduced field, `_is_heap_almost_full`, can also be used to impl what you proposed. IOW, this field enables us to detect and react to "emergency" state. (Just to make it explicit, this allocating-in-old-gen when heap is tight has been in Serial for long, and was mistakenly removed in JDK-8333786.) As for which approach is "better", we probably need to assess it after cleaning up some other related code/logic, e.g. heap/generation-resizing.

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

PR Comment: https://git.openjdk.org/jdk/pull/23270#issuecomment-2616065369

From wkemper at openjdk.org  Mon Jan 27 17:42:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 27 Jan 2025 17:42:47 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when
 not the fault of triggering heuristic [v2]
In-Reply-To: <IHu0084TdPHzsXBBxYqfGcmur84YSZe87_IoJ_ppCC4=.80f116b2-6589-45ea-8e25-e75409d03d6e@github.com>
References: <I23rSXtDTr6iBN7meafN7idhMkGOuBdh_kxL5EowYjI=.6d9abfad-482c-493f-9725-c66be896e43c@github.com>
 <IHu0084TdPHzsXBBxYqfGcmur84YSZe87_IoJ_ppCC4=.80f116b2-6589-45ea-8e25-e75409d03d6e@github.com>
Message-ID: <Us5HjIq56u7CQIg0NTyg63K4sL77sokz-87XzkxlGaA=.f9770393-f80b-4f88-b17f-f321f693ae54@github.com>

On Mon, 27 Jan 2025 02:05:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Shenandoah heuristics use a penalty mechanism to cause earlier GC triggers when recent concurrent GC cycles degenerate.  Degeneration is a stop-the-world remediation that allows GC to catch up when mutator allocations fail during concurrent GC.  The fact that we needed to degenerate indicates that we were overly optimistic in delaying the trigger that starts concurrent GC.
>> 
>> We have observed that it is common for degenerated GC cycles to cascade upon each other.  The condition that caused an initial degenerated cycle is often not fully resolved by the end of that degenerated cycle.  For example, the application may be experiencing a phase change and the GC heuristics are not yet attuned to the new behavior.  Furthermore, a degenerated GC may exacerbate the problem condition.  During the stop-the-world pause imposed by the first degenerated GC, work continues to accumulate in the form of new client requests that are buffered in network sockets until the end of that degenerated GC.
>> 
>> As originally implemented, each degeneration would "pile on" additional penalties.  These penalties cause the GC frequency to continue to increase.  And the expanding CPU load of GC makes it increasingly difficult for mutator threads to catchup.  The large penalties accumulated while we are trying to resolve the problem linger long after the problem condition has been resolved.
>> 
>> This change does not add further to the degeneration penalties if a new degenerated cycle occurs through no fault of the triggering mechanism.  We only add the degeneration penalty if the reason we are now degenerating can be attributed to a consciously late trigger by the heuristic.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to reviewer feedback

Thanks for the changes. If I may paraphrase the change as I understand it: the heuristic penalties will only be applied if the heuristic has declined more than `Penalty_Free_Declinations` (because we believe that means the heuristic is being too lazy). Back to back degenerated cycles will no longer pile on penalties. Sounds good to me.

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23305#pullrequestreview-2576140980

From mdoerr at openjdk.org  Mon Jan 27 18:43:52 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 27 Jan 2025 18:43:52 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v2]
In-Reply-To: <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
Message-ID: <_-InqfHBkqDBdTvSh1rVFqRwaOheEVL3oFT6IQguVlc=.ad1b33f0-4e52-452b-9ef6-396cbdc899ec@github.com>

On Mon, 27 Jan 2025 14:06:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
>> 
>> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
>> 
>> 
>> o = new MyObject();
>> if (...) {
>>     o.myField = ...;  // barrier elided only after this changeset
>>                       // (assuming no safepoint in the if condition)
>> }
>> 
>> 
>> or in initialization writes placed after exception-throwing checks:
>> 
>> 
>> o = new MyObject();
>> if (...) {
>>     throw new Exception("");
>> }
>> o.myField = ...;  // barrier elided only after this changeset
>>                   // (assuming no safepoint in the above if condition)
>> 
>> 
>> These patterns are commonly found in Java code, e.g. in the core libraries:
>> 
>> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
>> 
>> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
>> 
>> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
>> 
>> 
>> Object[] a = new Object[...];
>> for (int i = 0; i < a.length; i++) {
>>     a[i] = ...;  // barrier elided only after this changeset
>> }
>> 
>> 
>> or eliding barriers from array initialization writes with unknown array index:
>> 
>> 
>> Object[] a = new Object[...];
>> a[index] = ...;  // barrier elided only after this changeset
>> 
>> 
>> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_inde...
>
> Roberto Casta?eda Lozano 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 commit 'afcc2b0' into JDK-8346280-late-barrier-elision
>  - Add new test case (store after exception)
>  - Remove unused includes
>  - Remove temporary UseNewCode guard
>  - Use clearer names and document access API interface
>  - Move ZGC-specific barrier elision code to BarrierSetC2
>  - Set UseNewCode to true temporarily
>  - Make elide_mach_barrier virtual
>  - Move late barrier elision analysis from G1BarrierSetC2 to BarrierSetC2
>  - Initial implementation
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/afcc2b03...ab47d7f8

Thanks for updating it! The tests which previously failed were all green, but I'll rerun more tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2616611577

From aboldtch at openjdk.org  Tue Jan 28 06:34:54 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 28 Jan 2025 06:34:54 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full [v2]
In-Reply-To: <HT8p0uMZjQTaQ8fVBcgaFb-8aEUdj0KJ56uV7NVSCZA=.12867620-7a81-4dbb-9a06-b239c28124cd@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
 <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
 <5yhQ84Fzbn7O21cWYNDWXL9M1tbEO6-CLacA85-ODio=.b1fcd52e-bdad-43d3-b1b6-d205b6a461e1@github.com>
 <HT8p0uMZjQTaQ8fVBcgaFb-8aEUdj0KJ56uV7NVSCZA=.12867620-7a81-4dbb-9a06-b239c28124cd@github.com>
Message-ID: <EJa-fPmDyZD9ev8lEUHyba32awcpD0VWGexlH7E8Y0s=.b72e0e48-102e-44e6-bd72-cd6954296e56@github.com>

On Mon, 27 Jan 2025 15:26:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Parallel also has the problem of fragmentation, where a single large obj in the beginning of eden can cause a large hole in the end of old-gen, because objs can't cross generation boundary.
> 
> Parallel doesn't have the problem of running >1000 GCs before exit, captured by the attached bm, because Parallel implements `UseGCOverheadLimit`. (For this particular bm with the selected heap-size, this problematic scenario doesn't occur for Parallel. One can even dodge this problematic scenario in Serial by using a diff heap-size, e.g. 200m instead of 100m.)

Interesting. I said this because I observe the same behaviour (stuck running thousands of full GCs). When I tested it I was on a couple of weeks old JDK25 build cc198972022c94199d698461e2ac42afc0058fd7
GC logs:

$ ./images/jdk/bin/java -Xmx100m -XX:+UseParallelGC -Xlog:gc,gc+init StressAdd.java
[0.002s][info][gc,init] CardTable entry size: 512
[0.002s][info][gc     ] Using Parallel
[0.003s][info][gc,init] Version: 25-internal-LTS-2025-01-27-1224260.aboldtch... (release)
[0.003s][info][gc,init] CPUs: 32 total, 32 available
[0.003s][info][gc,init] Memory: 63773M
[0.003s][info][gc,init] Large Page Support: Disabled
[0.003s][info][gc,init] NUMA Support: Disabled
[0.003s][info][gc,init] Compressed Oops: Enabled (32-bit)
[0.003s][info][gc,init] Alignments: Space 512K, Generation 512K, Heap 2M
[0.003s][info][gc,init] Heap Min Capacity: 8M
[0.003s][info][gc,init] Heap Initial Capacity: 100M
[0.003s][info][gc,init] Heap Max Capacity: 100M
[0.003s][info][gc,init] Pre-touch: Disabled
[0.003s][info][gc,init] Parallel Workers: 23
[0.395s][info][gc     ] GC(0) Pause Young (Allocation Failure) 26M->5M(96M) 5.227ms
[0.493s][info][gc     ] GC(1) Pause Young (Allocation Failure) 30M->17M(96M) 13.714ms
[0.518s][info][gc     ] GC(2) Pause Young (Allocation Failure) 42M->38M(96M) 19.380ms
[0.600s][info][gc     ] GC(3) Pause Full (Allocation Failure) 77M->59M(96M) 75.591ms
[0.709s][info][gc     ] GC(4) Pause Full (Allocation Failure) 73M->70M(96M) 102.293ms
[...]
[852.306s][info][gc     ] GC(10073) Pause Full (Allocation Failure) 82M->82M(96M) 82.800ms
[852.387s][info][gc     ] GC(10074) Pause Full (Allocation Failure) 82M->82M(96M) 81.312ms
[852.470s][info][gc     ] GC(10075) Pause Full (Allocation Failure) 82M->82M(96M) 83.034ms
[852.553s][info][gc     ] GC(10076) Pause Full (Allocation Failure) 82M->82M(96M) 82.130ms
[852.634s][info][gc     ] GC(10077) Pause Full (Allocation Failure) 82M->82M(96M) 81.610ms
[852.714s][info][gc     ] GC(10078) Pause Full (Allocation Failure) 82M->82M(96M) 79.986ms
[852.797s][info][gc     ] GC(10079) Pause Full (Allocation Failure) 82M->82M(96M) 82.543ms
Killed 


(I also just retried this with jdk-25+7 , which has the same behaviour)

> That's another way to address the many-gc-before-exit problem. However, end users may get surprised with this "premature" OOM when heap still has a sizable margin till 100%. (Ofc, this is pure speculation.)

Yeah I agree. But it might still be the sensible behaviour. When running the GC in this degenerate mode, it might be better to just OOM. Something is probably misconfigured.


> I believe the newly introduced field, `_is_heap_almost_full`, can also be used to impl what you proposed. IOW, this field enables us to detect and react to "emergency" state. (Just to make it explicit, this allocating-in-old-gen when heap is tight has been in Serial for long, and was mistakenly removed in JDK-8333786.) As for which approach is "better", we probably need to assess it after cleaning up some other related code/logic, e.g. heap/generation-resizing.

Yeah.  This would require a lot more thought to get right and iron out all the kinks and interactions. However it would be nice if we could guarantee that we never get into what seemingly looks like an perpetual full GC loop (even if some tiny progress is made each iteration). Even if it comes at the cost of a "premature" OOM.

Only looked at this in the context of Serial, but this patch could still have this full GC problem. If there is an object which causes perpetual promotion failures in YC and cannot be compacted because of the generation boundaries in the full GC. And we have a pattern of smaller temporary allocations followed by an allocation which does not fit in old, but requires a YC to fit in young.


I think an alternative solution we thought about is that if the full GC could move the generation boundaries so that we can compact everything to old. (Have some elasticity, acting as a rubber band, which springs back once the old residency goes down). Down to some minimal young size. Resulting in something like:
```c++
  // If young-gen can handle this allocation, attempt young-gc firstly.
  bool should_run_young_gc = _young_gen->should_allocate(size, is_tlab);
  collect_at_safepoint(!should_run_young_gc);

  result = attempt_allocation(size, is_tlab, false /*first_only*/);
  if (result != nullptr) {
    return result;
  }

  if (_young_gen->is_minimal_sized()) {
     return nullptr; 
  }

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

PR Comment: https://git.openjdk.org/jdk/pull/23270#issuecomment-2618040514

From tschatzl at openjdk.org  Tue Jan 28 09:21:50 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 28 Jan 2025 09:21:50 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v6]
In-Reply-To: <k7xeGByZHN9-OG83aTQzU5OFM3aNuu6u8lXsoJAp36U=.b291cb28-31f3-4d76-9349-298ec9af7598@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
 <k7xeGByZHN9-OG83aTQzU5OFM3aNuu6u8lXsoJAp36U=.b291cb28-31f3-4d76-9349-298ec9af7598@github.com>
Message-ID: <ZfxN_X7dliUcYmP7okAzNs3WTnVQwCu18xYGJQNIkDI=.0085faa4-1418-4f2f-979f-2303c0b70bca@github.com>

On Sat, 25 Jan 2025 21:23:35 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
>> 
>> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup based on Yang's comment

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21089#pullrequestreview-2577570690

From shade at openjdk.org  Tue Jan 28 10:28:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 28 Jan 2025 10:28:53 GMT
Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in
 default modes
In-Reply-To: <3qSVdyJR6ozIeVTfuIoF8d6i2ETvOsxghb8lmvpjrCg=.ad527b3b-b250-49ab-b0c1-60a811aabf7f@github.com>
References: <iA5-e4hKspjLBJAniBWfSl6A57zlBVUC5cMSsWY-ack=.29cab729-0abc-4a10-8050-a119d95860ff@github.com>
 <3qSVdyJR6ozIeVTfuIoF8d6i2ETvOsxghb8lmvpjrCg=.ad527b3b-b250-49ab-b0c1-60a811aabf7f@github.com>
Message-ID: <Hnz9EEPZcedRCAfE1NIf3J6tgMgQudb1SeofacOIhBM=.ebdb4bbf-cc77-4936-af9a-c1dee93bbcda@github.com>

On Thu, 23 Jan 2025 18:10:03 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I think it may be a little more preferrable to clamp this to some interval so that the value does not get unreasonably large or unreasonably small

I think min heap size and max heap size already serve as good bounds here, and those are already handled by the ergonomics code. We "only" need to choose the point between min and max where a reasonable init size should be.

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

PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-2618590889

From qamai at openjdk.org  Tue Jan 28 11:13:54 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 28 Jan 2025 11:13:54 GMT
Subject: RFR: 8348278: Trim InitialRAMPercentage to improve startup in
 default modes
In-Reply-To: <iA5-e4hKspjLBJAniBWfSl6A57zlBVUC5cMSsWY-ack=.29cab729-0abc-4a10-8050-a119d95860ff@github.com>
References: <iA5-e4hKspjLBJAniBWfSl6A57zlBVUC5cMSsWY-ack=.29cab729-0abc-4a10-8050-a119d95860ff@github.com>
Message-ID: <09FfHiEkBUtqof8dGT7Lxuc1GzkdPyTgOlaKTNGLuP4=.7b256d3d-3c71-4cc3-a926-2ffdd7346757@github.com>

On Thu, 23 Jan 2025 11:27:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value.
> 
> I think cutting to 0.2% of RAM size gets us into good sweet spot:
>  - On huge 1024G machine, this yields 2G initial heap
>  - On reasonably sized 128G machine, this gives 256M initial heap
>  - On smaller 1G container, this gives 2M initial heap
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all`

That's fair, although as you note here initial heap size has an additional impact compared to the min and max heap size, so having its own upper bound may be justifiable.

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

PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-2618695156

From zgu at openjdk.org  Tue Jan 28 13:32:52 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 28 Jan 2025 13:32:52 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC [v6]
In-Reply-To: <k7xeGByZHN9-OG83aTQzU5OFM3aNuu6u8lXsoJAp36U=.b291cb28-31f3-4d76-9349-298ec9af7598@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
 <k7xeGByZHN9-OG83aTQzU5OFM3aNuu6u8lXsoJAp36U=.b291cb28-31f3-4d76-9349-298ec9af7598@github.com>
Message-ID: <tTiIBPIG6Bwvb0llid1m_VzTiJ47aPuOpAGMV0YVAVQ=.d538897a-7674-4e19-9832-7d145fc38d4c@github.com>

On Sat, 25 Jan 2025 21:23:35 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
>> 
>> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup based on Yang's comment

Thanks, @albertnetymk @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/21089#issuecomment-2618997767

From zgu at openjdk.org  Tue Jan 28 13:32:53 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 28 Jan 2025 13:32:53 GMT
Subject: Integrated: 8339668: Parallel: Adopt PartialArrayState to consolidate
 marking stack in Full GC
In-Reply-To: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
Message-ID: <8_OEuvx0XiUIITyunWBpKKNiPK-Zl_v79yPJaBRwanQ=.b3e6ad7e-ac10-40e0-9e6c-6f2c071979a3@github.com>

On Thu, 19 Sep 2024 14:01:39 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
> 
> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.

This pull request has now been integrated.

Changeset: 5fec9994
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5fec999474dd4e88299ca02fccce8332fa5766ec
Stats:     180 lines in 6 files changed: 61 ins; 43 del; 76 mod

8339668: Parallel: Adopt PartialArrayState to consolidate marking stack in Full GC

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

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

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

From lgxbslgx at gmail.com  Tue Jan 28 14:18:08 2025
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Tue, 28 Jan 2025 22:18:08 +0800
Subject: [Discussion] Serial GC: Expand young generation size
In-Reply-To: <CAPSsVqih4NyY76+1syvCziLhwH4im+gJe6_=6W+atBoC4hkq+Q@mail.gmail.com>
References: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>
 <SA3PR10MB7022AB3FB889B4ABF2400E85D3122@SA3PR10MB7022.namprd10.prod.outlook.com>
 <2DB4422C-73F3-4E27-B41B-6028A6BFF51E@kodewerk.com>
 <CAPSsVqih4NyY76+1syvCziLhwH4im+gJe6_=6W+atBoC4hkq+Q@mail.gmail.com>
Message-ID: <CAPSsVqiB=26PV-5LTtx9f6REMK3x=3F1CGcwjLFELug3BqUCYQ@mail.gmail.com>

Hi Albert,

When I reviewed the PR [2] of JDK-8346920 [1], I suspected that it would
make the bug JDK-8333386 [3] occur again.
Then I ran the test case `TestAbortOnVMOperationTimeout.java` in the
current mainline code and it failed again in the client VM again.
So, I submitted the PR [4] to fix it [3].

Best Regards,
-- Guoxiong

[1] https://bugs.openjdk.org/browse/JDK-8346920
[2] https://github.com/openjdk/jdk/pull/23270
[3] https://bugs.openjdk.org/browse/JDK-8333386
[4] https://github.com/openjdk/jdk/pull/23334

On Mon, Jan 13, 2025 at 11:52?PM Guoxiong Li <lgxbslgx at gmail.com> wrote:

> Hi Albert,
>
> Sorry for any delay. I bisect the related patches in several days.
>
> > Re https://bugs.openjdk.org/browse/JDK-8333386, I think your
> suggestion, "add the option `-XX:NewSize=65m`", is the way to go.
>
> When I run the test case `TestAbortOnVMOperationTimeout` [1] in current
> main-line code,
> the test case passed in the client VM. I bisected all the related patches
> these months
> and found the change (the test case passed) began at JDK-8333786 [2].
> Then I tried partial code of JDK-8333786 [2] in its previous patch (the
> code is in [3]),
> and finally I found the method
> `SerialHeap::should_try_older_generation_allocation` [4]
> in JDK-8333786 [2] makes the test case pass in the client VM.
> It is because such a change can make the
> `DefNewGeneration::compute_new_size`
> effective, and then the young-gen size can be expanded after the GC.
> So I think the JDK-8333386 [1] is not a bug now and the ticket can be
> closed.
> What do you think about it?
>
> > As for adding young-gen expansion support to Serial, it probably should
> have its own enhancement ticket.
> >
> > I am currently working on placing from/to spaces before eden inside
> young-gen as part of Parallel heap-auto-sizing. I believe Serial can use
> the same layout (from/to/eden, instead of eden/from/to) to facilitate
> eden/young-gen expansion. My 2c.
>
> Yes, the expansion should have its ticket and need more investigation and
> discussion. And this email line is the beginning of the discussion.
>
> Best Regards,
> -- Guoxiong
>
> [1] https://bugs.openjdk.org/browse/JDK-8333386
> [2] https://bugs.openjdk.org/browse/JDK-8333786
> <https://bugs.openjdk.org/browse/JDK-8333386>
> [3] https://bugs.openjdk.org/browse/JDK-
> <https://bugs.openjdk.org/browse/JDK-8333386>8335007
> <https://bugs.openjdk.org/browse/JDK-8333386>
> [4]
> https://github.com/openjdk/jdk/commit/6b961acb87c29027f2158c6b7a764f1276a0bf52#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626R286-R290
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250128/f62a442a/attachment-0001.htm>

From albert.m.yang at oracle.com  Tue Jan 28 14:56:33 2025
From: albert.m.yang at oracle.com (Albert Yang)
Date: Tue, 28 Jan 2025 14:56:33 +0000
Subject: [External] : Re: [Discussion] Serial GC: Expand young generation
 size
In-Reply-To: <CAPSsVqiB=26PV-5LTtx9f6REMK3x=3F1CGcwjLFELug3BqUCYQ@mail.gmail.com>
References: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>
 <SA3PR10MB7022AB3FB889B4ABF2400E85D3122@SA3PR10MB7022.namprd10.prod.outlook.com>
 <2DB4422C-73F3-4E27-B41B-6028A6BFF51E@kodewerk.com>
 <CAPSsVqih4NyY76+1syvCziLhwH4im+gJe6_=6W+atBoC4hkq+Q@mail.gmail.com>
 <CAPSsVqiB=26PV-5LTtx9f6REMK3x=3F1CGcwjLFELug3BqUCYQ@mail.gmail.com>
Message-ID: <SA3PR10MB7022616F027E0E9AD6AE7E7FD3EF2@SA3PR10MB7022.namprd10.prod.outlook.com>

Hi Guoxiong,

Thank you for taking care of it.

/Albert

________________________________________
From: Guoxiong Li <lgxbslgx at gmail.com>
Sent: Tuesday, January 28, 2025 15:18
To: Albert Yang
Cc: hotspot-gc-dev at openjdk.org
Subject: [External] : Re: [Discussion] Serial GC: Expand young generation size

Hi Albert,

When I reviewed the PR [2] of JDK-8346920 [1], I suspected that it would make the bug JDK-8333386 [3] occur again.
Then I ran the test case `TestAbortOnVMOperationTimeout.java` in the current mainline code and it failed again in the client VM again.
So, I submitted the PR [4] to fix it [3].

Best Regards,
-- Guoxiong

[1] https://bugs.openjdk.org/browse/JDK-8346920
[2] https://github.com/openjdk/jdk/pull/23270<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23270__;!!ACWV5N9M2RV99hQ!LdykVXWOE3AQ7CzbTj29hiM6_sgmDxvERhAY1gwB79Dlf-toBgx6MFJZmSqqC0snhTj5Uq8ICI0PcU8xe1FN$>
[3] https://bugs.openjdk.org/browse/JDK-8333386
[4] https://github.com/openjdk/jdk/pull/23334<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23334__;!!ACWV5N9M2RV99hQ!LdykVXWOE3AQ7CzbTj29hiM6_sgmDxvERhAY1gwB79Dlf-toBgx6MFJZmSqqC0snhTj5Uq8ICI0PcSWs6fAM$>

On Mon, Jan 13, 2025 at 11:52?PM Guoxiong Li <lgxbslgx at gmail.com<mailto:lgxbslgx at gmail.com>> wrote:
Hi Albert,

Sorry for any delay. I bisect the related patches in several days.

> Re https://bugs.openjdk.org/browse/JDK-8333386, I think your suggestion, "add the option `-XX:NewSize=65m`", is the way to go.

When I run the test case `TestAbortOnVMOperationTimeout` [1] in current main-line code,
the test case passed in the client VM. I bisected all the related patches these months
and found the change (the test case passed) began at JDK-8333786 [2].
Then I tried partial code of JDK-8333786 [2] in its previous patch (the code is in [3]),
and finally I found the method `SerialHeap::should_try_older_generation_allocation` [4]
in JDK-8333786 [2] makes the test case pass in the client VM.
It is because such a change can make the `DefNewGeneration::compute_new_size`
effective, and then the young-gen size can be expanded after the GC.
So I think the JDK-8333386 [1] is not a bug now and the ticket can be closed.
What do you think about it?

> As for adding young-gen expansion support to Serial, it probably should have its own enhancement ticket.
>
> I am currently working on placing from/to spaces before eden inside young-gen as part of Parallel heap-auto-sizing. I believe Serial can use the same layout (from/to/eden, instead of eden/from/to) to facilitate eden/young-gen expansion. My 2c.

Yes, the expansion should have its ticket and need more investigation and discussion. And this email line is the beginning of the discussion.

Best Regards,
-- Guoxiong

[1] https://bugs.openjdk.org/browse/JDK-8333386
[2] https://bugs.openjdk.org/browse/JDK-8333786<https://bugs.openjdk.org/browse/JDK-8333386>
[3] https://bugs.openjdk.org/browse/JDK-<https://bugs.openjdk.org/browse/JDK-8333386>8335007<https://bugs.openjdk.org/browse/JDK-8333386>
[4] https://github.com/openjdk/jdk/commit/6b961acb87c29027f2158c6b7a764f1276a0bf52#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626R286-R290<https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/6b961acb87c29027f2158c6b7a764f1276a0bf52*diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626R286-R290__;Iw!!ACWV5N9M2RV99hQ!LdykVXWOE3AQ7CzbTj29hiM6_sgmDxvERhAY1gwB79Dlf-toBgx6MFJZmSqqC0snhTj5Uq8ICI0PcTSXqVVs$>


From ayang at openjdk.org  Tue Jan 28 16:15:56 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 28 Jan 2025 16:15:56 GMT
Subject: RFR: 8346920: Serial: Support allocation in old generation when
 heap is almost full [v2]
In-Reply-To: <EJa-fPmDyZD9ev8lEUHyba32awcpD0VWGexlH7E8Y0s=.b72e0e48-102e-44e6-bd72-cd6954296e56@github.com>
References: <dbJ9v79ri-Y_XZwr8xrXBTFut3ocRK9ktpK1EuJFLQQ=.a24d87d0-fbe5-4d43-a7cd-31c2a4901cae@github.com>
 <Itq_adUHVfyxDTKfe_sa-B09ydeDM2NUgdDQtP-RinE=.fa04e381-6d61-4a93-82f2-b60979c983bf@github.com>
 <5yhQ84Fzbn7O21cWYNDWXL9M1tbEO6-CLacA85-ODio=.b1fcd52e-bdad-43d3-b1b6-d205b6a461e1@github.com>
 <HT8p0uMZjQTaQ8fVBcgaFb-8aEUdj0KJ56uV7NVSCZA=.12867620-7a81-4dbb-9a06-b239c28124cd@github.com>
 <EJa-fPmDyZD9ev8lEUHyba32awcpD0VWGexlH7E8Y0s=.b72e0e48-102e-44e6-bd72-cd6954296e56@github.com>
Message-ID: <gkAmPX5VeBSAMHSnSVDDiWtfHgr-6qPLD5d0m2UQ43U=.7a77b155-a24f-4b2f-8de2-4527e4017976@github.com>

On Tue, 28 Jan 2025 06:32:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Interesting. I said this because I observe the same behaviour (stuck running thousands of full GCs).

I can't reproduce it on my box. (I suspect the bm is not targeted to that problematic scenario, so diff boxes get diff objs layout. Not too surprising.) I'd expected `UseGCOverheadLimit` to kick in, but sth must have messed up...

> Only looked at this in the context of Serial, but this patch could still have this full GC problem...

I believe you are referring to a scenario where each young/full gc makes some progress, but the reclaimed memory is barely/just enough for the following single allocation, sth like `alloc(size) + alloc(size) + gc + alloc(size) + alloc(size) + gc`.

Since each gc reclaims some mem, it's diff from the scenario where the original bm captured. I believe `UseGCOverheadLimit` is meant for such scenario, where each gc is effective, but too much cpu-time is spent on gc in total.

(Serial doesn't support `UseGCOverheadLimit`; Parallel does, but according to your experiment, Parallel's support is incomplete... I will fix the Parallel case firstly as part of [JDK-8338977](https://bugs.openjdk.org/browse/JDK-8338977).)

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

PR Comment: https://git.openjdk.org/jdk/pull/23270#issuecomment-2619450483

From tschatzl at openjdk.org  Tue Jan 28 19:58:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 28 Jan 2025 19:58:47 GMT
Subject: RFR: 8333386: TestAbortOnVMOperationTimeout test fails for client
 VM
In-Reply-To: <5UA8MLmX5k0C3B2ujKO-kSCe4npICDf8JTrFjbyx8x8=.9656289f-5028-49b8-b486-30ace4b0b9e5@github.com>
References: <5UA8MLmX5k0C3B2ujKO-kSCe4npICDf8JTrFjbyx8x8=.9656289f-5028-49b8-b486-30ace4b0b9e5@github.com>
Message-ID: <TlEhCjDa7xh3SQJdXLFIpB_P874VFQimtw-t8FhCh6s=.c7b13111-6412-4ad3-9e21-0099ff6eb721@github.com>

On Tue, 28 Jan 2025 14:09:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The test case `TestAbortOnVMOperationTimeout.java` fails on client VM, 
> because the default new generation size is low and the new size can't be expanded when allocating. 
> It is good to set the new size explicitly so that the test case can pass on the client VM.
> 
> Thanks for your review.
> 
> Best Regards,
> -- Guoxiong

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23334#pullrequestreview-2579285430

From gli at openjdk.org  Wed Jan 29 14:39:54 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 29 Jan 2025 14:39:54 GMT
Subject: RFR: 8333386: TestAbortOnVMOperationTimeout test fails for client
 VM
In-Reply-To: <5UA8MLmX5k0C3B2ujKO-kSCe4npICDf8JTrFjbyx8x8=.9656289f-5028-49b8-b486-30ace4b0b9e5@github.com>
References: <5UA8MLmX5k0C3B2ujKO-kSCe4npICDf8JTrFjbyx8x8=.9656289f-5028-49b8-b486-30ace4b0b9e5@github.com>
Message-ID: <WJn5G3SHg0nK132R5POPegM2y4_NZYx6A7pyLqYjq6A=.f8e16816-2383-40b8-8a90-3c9798b3ef48@github.com>

On Tue, 28 Jan 2025 14:09:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The test case `TestAbortOnVMOperationTimeout.java` fails on client VM, 
> because the default new generation size is low and the new size can't be expanded when allocating. 
> It is good to set the new size explicitly so that the test case can pass on the client VM.
> 
> Thanks for your review.
> 
> Best Regards,
> -- Guoxiong

Thanks for your reviews. Integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/23334#issuecomment-2621829859

From gli at openjdk.org  Wed Jan 29 14:39:55 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 29 Jan 2025 14:39:55 GMT
Subject: Integrated: 8333386: TestAbortOnVMOperationTimeout test fails for
 client VM
In-Reply-To: <5UA8MLmX5k0C3B2ujKO-kSCe4npICDf8JTrFjbyx8x8=.9656289f-5028-49b8-b486-30ace4b0b9e5@github.com>
References: <5UA8MLmX5k0C3B2ujKO-kSCe4npICDf8JTrFjbyx8x8=.9656289f-5028-49b8-b486-30ace4b0b9e5@github.com>
Message-ID: <RmhqeARfKCG-bMETC3ts4UHB5foAo1GkgTVnWb2eZUE=.b5820beb-0f16-4413-8a3c-3fcc54220eac@github.com>

On Tue, 28 Jan 2025 14:09:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The test case `TestAbortOnVMOperationTimeout.java` fails on client VM, 
> because the default new generation size is low and the new size can't be expanded when allocating. 
> It is good to set the new size explicitly so that the test case can pass on the client VM.
> 
> Thanks for your review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 6bfae3ac
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6bfae3acc107e046294bfc2e535ccddc99205490
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8333386: TestAbortOnVMOperationTimeout test fails for client VM

Reviewed-by: ayang, tschatzl

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

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

From mdoerr at openjdk.org  Wed Jan 29 17:34:53 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 29 Jan 2025 17:34:53 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v2]
In-Reply-To: <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
Message-ID: <oiGLwezfGthnGNMvsc_nl_YlabubqdPqjpbr_-v5Dz4=.6f2f7d71-fcd6-48be-9889-95e10a60c9e6@github.com>

On Mon, 27 Jan 2025 14:06:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
>> 
>> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
>> 
>> 
>> o = new MyObject();
>> if (...) {
>>     o.myField = ...;  // barrier elided only after this changeset
>>                       // (assuming no safepoint in the if condition)
>> }
>> 
>> 
>> or in initialization writes placed after exception-throwing checks:
>> 
>> 
>> o = new MyObject();
>> if (...) {
>>     throw new Exception("");
>> }
>> o.myField = ...;  // barrier elided only after this changeset
>>                   // (assuming no safepoint in the above if condition)
>> 
>> 
>> These patterns are commonly found in Java code, e.g. in the core libraries:
>> 
>> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
>> 
>> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
>> 
>> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
>> 
>> 
>> Object[] a = new Object[...];
>> for (int i = 0; i < a.length; i++) {
>>     a[i] = ...;  // barrier elided only after this changeset
>> }
>> 
>> 
>> or eliding barriers from array initialization writes with unknown array index:
>> 
>> 
>> Object[] a = new Object[...];
>> a[index] = ...;  // barrier elided only after this changeset
>> 
>> 
>> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_inde...
>
> Roberto Casta?eda Lozano 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 commit 'afcc2b0' into JDK-8346280-late-barrier-elision
>  - Add new test case (store after exception)
>  - Remove unused includes
>  - Remove temporary UseNewCode guard
>  - Use clearer names and document access API interface
>  - Move ZGC-specific barrier elision code to BarrierSetC2
>  - Set UseNewCode to true temporarily
>  - Make elide_mach_barrier virtual
>  - Move late barrier elision analysis from G1BarrierSetC2 to BarrierSetC2
>  - Initial implementation
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/afcc2b03...ab47d7f8

There was some noise due to other issues, but nothing which looks related to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2622400615

From wkemper at openjdk.org  Wed Jan 29 21:58:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 29 Jan 2025 21:58:18 GMT
Subject: RFR: 8349002: GenShen: Deadlock during shutdown
Message-ID: <c6pJ1S_4ut4GumV8-9HIkZ-5PfNyrTQuRW_AbdQjln4=.502c3829-95f7-4f59-a648-179a083d8449@github.com>

[JDK-8345970](https://bugs.openjdk.org/browse/JDK-8345970) changed the order in which the control thread and regulator thread are shutdown. The new order (in which the control thread is shutdown first), may leave the regulator thread waiting indefinitely for a gc cycle that will never start.

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

Commit messages:
 - Change gc mode to 'stopped' when the control thread has been stopped

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

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

From rcastanedalo at openjdk.org  Thu Jan 30 08:19:47 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 30 Jan 2025 08:19:47 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v2]
In-Reply-To: <oiGLwezfGthnGNMvsc_nl_YlabubqdPqjpbr_-v5Dz4=.6f2f7d71-fcd6-48be-9889-95e10a60c9e6@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
 <oiGLwezfGthnGNMvsc_nl_YlabubqdPqjpbr_-v5Dz4=.6f2f7d71-fcd6-48be-9889-95e10a60c9e6@github.com>
Message-ID: <FLdTcmKvu_OL9lyUjw04PEc4j6H0uhOhNQ6sbH5Xcs4=.f9258283-1dbe-47a3-a9a3-c2206b3c1699@github.com>

On Wed, 29 Jan 2025 17:31:48 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> There was some noise due to other issues, but nothing which looks related to this PR.

Thanks for re-testing, Martin!

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2623814163

From manc at google.com  Thu Jan 30 09:06:16 2025
From: manc at google.com (Man Cao)
Date: Thu, 30 Jan 2025 01:06:16 -0800
Subject: GCOverheadLimit support for G1
In-Reply-To: <c8c48a88-66af-4d95-af57-5927902035b9@oracle.com>
References: <CADo2k6tfD4T-WP9RUdZPFGjPh7rbf=_hVQpdZCGCsTuQ5DwtKg@mail.gmail.com>
 <ad5a5bcf-3c5e-486c-b4e0-36ee68b6538f@oracle.com>
 <c8c48a88-66af-4d95-af57-5927902035b9@oracle.com>
Message-ID: <CA+w6HxbGuOZ1cU0C+OgOP_ZXpOhfQFNPcB0uWXURAMeCvb9knQ@mail.gmail.com>

+1 to Thomas's response.
I added a comment in https://bugs.openjdk.org/browse/JDK-8212084 for
the current status, and unassigned myself.

-Man
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250130/434c41d6/attachment.htm>

From ayang at openjdk.org  Thu Jan 30 12:18:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 30 Jan 2025 12:18:55 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring memory
 leading to OOME
Message-ID: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>

Here is an attempt to simplify GCLocker implementation for Serial and Parallel.

GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.

The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.

Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.

Test: tier1-8

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

Commit messages:
 - gclocker

Changes: https://git.openjdk.org/jdk/pull/23367/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8192647
  Stats: 936 lines in 37 files changed: 36 ins; 804 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/23367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23367/head:pull/23367

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

From shade at openjdk.org  Thu Jan 30 13:08:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 Jan 2025 13:08:47 GMT
Subject: RFR: 8349002: GenShen: Deadlock during shutdown
In-Reply-To: <c6pJ1S_4ut4GumV8-9HIkZ-5PfNyrTQuRW_AbdQjln4=.502c3829-95f7-4f59-a648-179a083d8449@github.com>
References: <c6pJ1S_4ut4GumV8-9HIkZ-5PfNyrTQuRW_AbdQjln4=.502c3829-95f7-4f59-a648-179a083d8449@github.com>
Message-ID: <Vedcf1uIE90161O1KvK6Hn6NMHngt0EQ9xS5_SrJae8=.73ef68bf-31b9-408d-9932-b70fd52232f2@github.com>

On Wed, 29 Jan 2025 21:53:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> [JDK-8345970](https://bugs.openjdk.org/browse/JDK-8345970) changed the order in which the control thread and regulator thread are shutdown. The new order (in which the control thread is shutdown first), may leave the regulator thread waiting indefinitely for a gc cycle that will never start.

So, setting GC mode to `stopped` is enough to notify regulator thread that it should exit? If so, looks fine.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23358#pullrequestreview-2583855191

From gli at openjdk.org  Thu Jan 30 14:30:52 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 30 Jan 2025 14:30:52 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v2]
In-Reply-To: <ftzWhSa3GNKdOL-uB9velHPnXqlbr7F08ljiYB-7uY8=.13a224cc-93b3-4425-a57a-67e0e0ad3257@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
 <ftzWhSa3GNKdOL-uB9velHPnXqlbr7F08ljiYB-7uY8=.13a224cc-93b3-4425-a57a-67e0e0ad3257@github.com>
Message-ID: <g4G2yvX60r88lgiEYINoMak5VvCsucls14XnC-yKnGQ=.6e7d8236-9ac9-471b-81a4-076615543dd8@github.com>

On Tue, 21 Jan 2025 14:43:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of removing the use of `virtual` method and use concrete subclasses when needed.
>> 
>> Test: tier1-5
>
> 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 two commits:
> 
>  - merge
>  - gen-counter

Several nits/questions.

I am not familiar with the Shenandoah GC, but it is not much modified in this patch. It may be good for a Shenandoah maintainer/developer to review/comfirm this PR.

src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.hpp line 31:

> 29: 
> 30: class EpsilonGenerationCounters;
> 31: class GenerationCounters;

The pre-declaration `GenerationCounters` seems be not needed now. Same in `shenandoahMonitoringSupport.hpp`.

src/hotspot/share/gc/parallel/psYoungGen.cpp line 95:

> 93:   // Generation Counters - generation 0, 3 subspaces
> 94:   _gen_counters = new GenerationCounters("new", 0, 3, min_gen_size(),
> 95:                                          max_gen_size(), virtual_space()->committed_size());

Question:
I notice the `virtual_space()->committed_size()` here is not the same as `_virtual_space.committed_size()` of Serial GC. Because one is a pointer and another is just an pure object instead of a pointer. Why are they different?  Is this difference occasional or one convention I don't know before?

src/hotspot/share/gc/shared/generationCounters.cpp line 72:

> 70: void GenerationCounters::update_all(size_t curr_capacity) {
> 71:   _current_size->set_value(curr_capacity);
> 72: }

I don't think the `update_all` is a good method name because it only modifies the current capacity(committed size). But this method had been used since OpenJDK opened source, so we don't know its commit history before opening source. Maybe the method name `update_capacity` in the class `ZGenerationCounters` is a better name we can adopt here.

src/hotspot/share/gc/shared/generationCounters.hpp line 54:

> 52:   GenerationCounters(const char* name, int ordinal, int spaces,
> 53:                    size_t min_capacity, size_t max_capacity,
> 54:                    size_t curr_capacity);

Some parameters or arguments formats, like this one, can be adjusted/aligned. It seems an IDE automatical alignment. So, it is not a big problem.

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

Changes requested by gli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23209#pullrequestreview-2583810474
PR Review Comment: https://git.openjdk.org/jdk/pull/23209#discussion_r1935554161
PR Review Comment: https://git.openjdk.org/jdk/pull/23209#discussion_r1935650179
PR Review Comment: https://git.openjdk.org/jdk/pull/23209#discussion_r1935668622
PR Review Comment: https://git.openjdk.org/jdk/pull/23209#discussion_r1935679850

From ayang at openjdk.org  Thu Jan 30 14:59:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 30 Jan 2025 14:59:04 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v3]
In-Reply-To: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
Message-ID: <JTiEx6zF8THHeo0OSfz38SheTjK8qP0Mh1Ua6SemPqM=.dc9dbaaf-424f-442a-a6af-f57b06e7b6ed@github.com>

> Simple refactoring of removing the use of `virtual` method and use concrete subclasses when needed.
> 
> Test: tier1-5

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 four commits:

 - review
 - Merge branch 'master' into gen-counter
 - merge
 - gen-counter

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

Changes: https://git.openjdk.org/jdk/pull/23209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23209&range=02
  Stats: 193 lines in 16 files changed: 6 ins; 156 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/23209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23209/head:pull/23209

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

From ayang at openjdk.org  Thu Jan 30 14:59:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 30 Jan 2025 14:59:07 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v2]
In-Reply-To: <g4G2yvX60r88lgiEYINoMak5VvCsucls14XnC-yKnGQ=.6e7d8236-9ac9-471b-81a4-076615543dd8@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
 <ftzWhSa3GNKdOL-uB9velHPnXqlbr7F08ljiYB-7uY8=.13a224cc-93b3-4425-a57a-67e0e0ad3257@github.com>
 <g4G2yvX60r88lgiEYINoMak5VvCsucls14XnC-yKnGQ=.6e7d8236-9ac9-471b-81a4-076615543dd8@github.com>
Message-ID: <Jx8pS7pMHOcQbuA00IXCqfqHVqhdp6gBf_5DH6YlYwE=.a22f8cd0-3f12-403a-8b95-cbd5936ee296@github.com>

On Thu, 30 Jan 2025 13:53:13 GMT, Guoxiong Li <gli 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 two commits:
>> 
>>  - merge
>>  - gen-counter
>
> src/hotspot/share/gc/parallel/psYoungGen.cpp line 95:
> 
>> 93:   // Generation Counters - generation 0, 3 subspaces
>> 94:   _gen_counters = new GenerationCounters("new", 0, 3, min_gen_size(),
>> 95:                                          max_gen_size(), virtual_space()->committed_size());
> 
> Question:
> I notice the `virtual_space()->committed_size()` here is not the same as `_virtual_space.committed_size()` of Serial GC. Because one is a pointer and another is just an pure object instead of a pointer. Why are they different?  Is this difference occasional or one convention I don't know before?

I don't think there is a fundamental reason that they have to be different. We can probably uniform them, but the benefit seems small, IMO.

> src/hotspot/share/gc/shared/generationCounters.cpp line 72:
> 
>> 70: void GenerationCounters::update_all(size_t curr_capacity) {
>> 71:   _current_size->set_value(curr_capacity);
>> 72: }
> 
> I don't think the `update_all` is a good method name because it only modifies the current capacity(committed size). But this method had been used since OpenJDK opened source, so we don't know its commit history before opening source. Maybe the method name `update_capacity` in the class `ZGenerationCounters` is a better name we can adopt here.

I agree the current name can be improved to sth like `update_capacity`, but it also seems that such renaming can/should be done in its own PR, so I kept it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23209#discussion_r1935731114
PR Review Comment: https://git.openjdk.org/jdk/pull/23209#discussion_r1935737525

From gli at openjdk.org  Thu Jan 30 15:23:52 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 30 Jan 2025 15:23:52 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v2]
In-Reply-To: <Jx8pS7pMHOcQbuA00IXCqfqHVqhdp6gBf_5DH6YlYwE=.a22f8cd0-3f12-403a-8b95-cbd5936ee296@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
 <ftzWhSa3GNKdOL-uB9velHPnXqlbr7F08ljiYB-7uY8=.13a224cc-93b3-4425-a57a-67e0e0ad3257@github.com>
 <g4G2yvX60r88lgiEYINoMak5VvCsucls14XnC-yKnGQ=.6e7d8236-9ac9-471b-81a4-076615543dd8@github.com>
 <Jx8pS7pMHOcQbuA00IXCqfqHVqhdp6gBf_5DH6YlYwE=.a22f8cd0-3f12-403a-8b95-cbd5936ee296@github.com>
Message-ID: <bajHY8GUwa1zgM23-PLzdaP_wPM7pxn-A2r95PRaBtM=.4fc20200-4337-41ec-ada0-fae42c8c96e3@github.com>

On Thu, 30 Jan 2025 14:48:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> We can probably uniform them, but the benefit seems small, IMO.

OK, I also think so.

>> src/hotspot/share/gc/shared/generationCounters.cpp line 72:
>> 
>>> 70: void GenerationCounters::update_all(size_t curr_capacity) {
>>> 71:   _current_size->set_value(curr_capacity);
>>> 72: }
>> 
>> I don't think the `update_all` is a good method name because it only modifies the current capacity(committed size). But this method had been used since OpenJDK opened source, so we don't know its commit history before opening source. Maybe the method name `update_capacity` in the class `ZGenerationCounters` is a better name we can adopt here.
>
> I agree the current name can be improved to sth like `update_capacity`, but it also seems that such renaming can/should be done in its own PR, so I kept it as is.

Filed https://bugs.openjdk.org/browse/JDK-8349077 to follow up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23209#discussion_r1935801820
PR Review Comment: https://git.openjdk.org/jdk/pull/23209#discussion_r1935800322

From lgxbslgx at gmail.com  Thu Jan 30 15:29:13 2025
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Thu, 30 Jan 2025 23:29:13 +0800
Subject: [Discussion] Serial GC: Expand young generation size
In-Reply-To: <CAPSsVqiB=26PV-5LTtx9f6REMK3x=3F1CGcwjLFELug3BqUCYQ@mail.gmail.com>
References: <CAPSsVqjZkCAMYQXR0QHTJRjSY-ZpiSciApHrUZA9oXkOAFrXUQ@mail.gmail.com>
 <SA3PR10MB7022AB3FB889B4ABF2400E85D3122@SA3PR10MB7022.namprd10.prod.outlook.com>
 <2DB4422C-73F3-4E27-B41B-6028A6BFF51E@kodewerk.com>
 <CAPSsVqih4NyY76+1syvCziLhwH4im+gJe6_=6W+atBoC4hkq+Q@mail.gmail.com>
 <CAPSsVqiB=26PV-5LTtx9f6REMK3x=3F1CGcwjLFELug3BqUCYQ@mail.gmail.com>
Message-ID: <CAPSsVqiGcnRKeZ4-rHfjRL0+jRsn5s4iX6Y=R6FsYrkqj77iUA@mail.gmail.com>

>> As for adding young-gen expansion support to Serial, it probably should
have its own enhancement ticket.

>   Yes, the expansion should have its ticket and need more investigation
and discussion.

Filed https://bugs.openjdk.org/browse/JDK-8349079 to follow up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250130/914f88d6/attachment.htm>

From wkemper at openjdk.org  Thu Jan 30 16:55:46 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Jan 2025 16:55:46 GMT
Subject: RFR: 8349002: GenShen: Deadlock during shutdown
In-Reply-To: <c6pJ1S_4ut4GumV8-9HIkZ-5PfNyrTQuRW_AbdQjln4=.502c3829-95f7-4f59-a648-179a083d8449@github.com>
References: <c6pJ1S_4ut4GumV8-9HIkZ-5PfNyrTQuRW_AbdQjln4=.502c3829-95f7-4f59-a648-179a083d8449@github.com>
Message-ID: <biBMbUQHd7koOUS9rHbTLrpu6V6Th3pAMHu16-U1U_0=.a1c8641b-4849-4a8a-99d2-971e41c910ae@github.com>

On Wed, 29 Jan 2025 21:53:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> [JDK-8345970](https://bugs.openjdk.org/browse/JDK-8345970) changed the order in which the control thread and regulator thread are shutdown. The new order (in which the control thread is shutdown first), may leave the regulator thread waiting indefinitely for a gc cycle that will never start.

Yes, the regulator thread is in a wait loop until the gc mode is not `none`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23358#issuecomment-2625045467

From wkemper at openjdk.org  Thu Jan 30 17:04:59 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Jan 2025 17:04:59 GMT
Subject: Integrated: 8349002: GenShen: Deadlock during shutdown
In-Reply-To: <c6pJ1S_4ut4GumV8-9HIkZ-5PfNyrTQuRW_AbdQjln4=.502c3829-95f7-4f59-a648-179a083d8449@github.com>
References: <c6pJ1S_4ut4GumV8-9HIkZ-5PfNyrTQuRW_AbdQjln4=.502c3829-95f7-4f59-a648-179a083d8449@github.com>
Message-ID: <1G3y4EYnLMgt0lF7EiyKIXUsHhpBuCgLjHw3K3TvGuA=.509c0eaf-d9ac-4a08-835f-fb8b817c9d73@github.com>

On Wed, 29 Jan 2025 21:53:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> [JDK-8345970](https://bugs.openjdk.org/browse/JDK-8345970) changed the order in which the control thread and regulator thread are shutdown. The new order (in which the control thread is shutdown first), may leave the regulator thread waiting indefinitely for a gc cycle that will never start.

This pull request has now been integrated.

Changeset: 06ebb170
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/06ebb170bac3879dc1e378b48b1c7ef006070c86
Stats:     5 lines in 2 files changed: 4 ins; 0 del; 1 mod

8349002: GenShen: Deadlock during shutdown

Reviewed-by: shade

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

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

From xpeng at openjdk.org  Fri Jan 31 01:18:48 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 31 Jan 2025 01:18:48 GMT
Subject: RFR: 8348595: GenShen: Fix generational free-memory no-progress
 check
In-Reply-To: <qxVLivQe7QASskJibcjSy-PmAXScg3r7k4Rdomvzws0=.03982de5-8ae8-4a9a-b940-d0990e27ff84@github.com>
References: <qxVLivQe7QASskJibcjSy-PmAXScg3r7k4Rdomvzws0=.03982de5-8ae8-4a9a-b940-d0990e27ff84@github.com>
Message-ID: <BUeokbLWxbV2laEURYDBv2jFqmM2dS7Q0MiN5COnGhg=.d37408d4-ac5b-4271-bf16-6a097a0b80d1@github.com>

On Fri, 24 Jan 2025 18:30:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> At the end of a degenerated GC, we check whether sufficient progress has been made in replenishing the memory available to the mutator. The test for good progress is implemented as a ratio of free memory against the total heap size.
> 
> For generational Shenandoah, the ratio should be computed against the size of the young generation. Note that the size of the generational collection set is based on young generation size rather than total heap size.
> 
> This issue first identified in GenShen GC logs, where a large number of degenerated cycles were upgrading to full GC because the free-set progress was short of desired by 10-25%.

src/hotspot/share/gc/shenandoah/shenandoahMetrics.cpp line 52:

> 50:   size_t free_actual   = free_set->available();
> 51:   // The sum of free_set->capacity() and ->reserved represents capacity of young in generational, heap in non-generational.
> 52:   size_t free_expected = ((free_set->capacity() + free_set->reserved()) / 100) * ShenandoahCriticalFreeThreshold;

We may pass ShenandoahGeneration as parameter to `is_good_progress` to simplify the calculation of free_expected, it should be like:
`
generation->max_capacity() / 100 * ShenandoahCriticalFreeThreshold
`
Good part is, free_expected might be more accurate in Full GC/Degen for global cycle, e.g. Full GC collects memory for global, `free_expected` should be calculated using the metrics from global generation. But either way, `free_expected` is not clearly defined in generational mode now, current code also works.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23306#discussion_r1936527761

From gli at openjdk.org  Fri Jan 31 04:22:53 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 31 Jan 2025 04:22:53 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v3]
In-Reply-To: <JTiEx6zF8THHeo0OSfz38SheTjK8qP0Mh1Ua6SemPqM=.dc9dbaaf-424f-442a-a6af-f57b06e7b6ed@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
 <JTiEx6zF8THHeo0OSfz38SheTjK8qP0Mh1Ua6SemPqM=.dc9dbaaf-424f-442a-a6af-f57b06e7b6ed@github.com>
Message-ID: <eopk5d9VcbJt2CvdhUqoU6OO4fVHgW2EEh_vd03dBQ4=.2bd2e43b-8f71-4722-b05b-83e2b689e0e2@github.com>

On Thu, 30 Jan 2025 14:59:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of removing the use of `virtual` method and use concrete subclasses when needed.
>> 
>> Test: tier1-5
>
> 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 four commits:
> 
>  - review
>  - Merge branch 'master' into gen-counter
>  - merge
>  - gen-counter

Marked as reviewed by gli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23209#pullrequestreview-2585635058

From tschatzl at openjdk.org  Fri Jan 31 08:57:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 31 Jan 2025 08:57:52 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v2]
In-Reply-To: <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
Message-ID: <gD0K0nnWjN5S1njkKZ3rkIT0UKnEbT5KIZpayS8VgVg=.99555536-ec9b-4a4b-97fb-124d4c26d924@github.com>

On Mon, 27 Jan 2025 14:06:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
>> 
>> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
>> 
>> 
>> o = new MyObject();
>> if (...) {
>>     o.myField = ...;  // barrier elided only after this changeset
>>                       // (assuming no safepoint in the if condition)
>> }
>> 
>> 
>> or in initialization writes placed after exception-throwing checks:
>> 
>> 
>> o = new MyObject();
>> if (...) {
>>     throw new Exception("");
>> }
>> o.myField = ...;  // barrier elided only after this changeset
>>                   // (assuming no safepoint in the above if condition)
>> 
>> 
>> These patterns are commonly found in Java code, e.g. in the core libraries:
>> 
>> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
>> 
>> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
>> 
>> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
>> 
>> 
>> Object[] a = new Object[...];
>> for (int i = 0; i < a.length; i++) {
>>     a[i] = ...;  // barrier elided only after this changeset
>> }
>> 
>> 
>> or eliding barriers from array initialization writes with unknown array index:
>> 
>> 
>> Object[] a = new Object[...];
>> a[index] = ...;  // barrier elided only after this changeset
>> 
>> 
>> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_inde...
>
> Roberto Casta?eda Lozano 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 commit 'afcc2b0' into JDK-8346280-late-barrier-elision
>  - Add new test case (store after exception)
>  - Remove unused includes
>  - Remove temporary UseNewCode guard
>  - Use clearer names and document access API interface
>  - Move ZGC-specific barrier elision code to BarrierSetC2
>  - Set UseNewCode to true temporarily
>  - Make elide_mach_barrier virtual
>  - Move late barrier elision analysis from G1BarrierSetC2 to BarrierSetC2
>  - Initial implementation
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/afcc2b03...ab47d7f8

One question about elision for atomics.

Otherwise it seems good afaict, although a large part was checking that the code movement is/was correct.

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 570:

> 568:         }
> 569:         break;
> 570:       default:

ZGC also tries to elide barriers for atomic ops. Why isn't this done for G1 too?

src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 956:

> 954: static bool is_unknown(intptr_t offset) {
> 955:   return offset == Type::OffsetBot;
> 956: }

pre-existing: these two predicates would be nice to have elsewhere in C2 code too (i.e. there's quite a lot of these predicates inlined elsewhere).

src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 1048:

> 1046:     return false;
> 1047:   }
> 1048:   const TypePtr* const adr_type = nullptr;

pre-existing: `adr_type` is unused in the following.

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

PR Review: https://git.openjdk.org/jdk/pull/23235#pullrequestreview-2585987704
PR Review Comment: https://git.openjdk.org/jdk/pull/23235#discussion_r1936888147
PR Review Comment: https://git.openjdk.org/jdk/pull/23235#discussion_r1936882659
PR Review Comment: https://git.openjdk.org/jdk/pull/23235#discussion_r1936866887

From tschatzl at openjdk.org  Fri Jan 31 08:57:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 31 Jan 2025 08:57:52 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v2]
In-Reply-To: <gD0K0nnWjN5S1njkKZ3rkIT0UKnEbT5KIZpayS8VgVg=.99555536-ec9b-4a4b-97fb-124d4c26d924@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
 <gD0K0nnWjN5S1njkKZ3rkIT0UKnEbT5KIZpayS8VgVg=.99555536-ec9b-4a4b-97fb-124d4c26d924@github.com>
Message-ID: <TopoY6okYG6ZXRzFixx7ZXEJTvl5YhG1R3Om40StDIQ=.846da9bd-6720-4a2d-9a9e-0087f420962b@github.com>

On Fri, 31 Jan 2025 08:48:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roberto Casta?eda Lozano 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 commit 'afcc2b0' into JDK-8346280-late-barrier-elision
>>  - Add new test case (store after exception)
>>  - Remove unused includes
>>  - Remove temporary UseNewCode guard
>>  - Use clearer names and document access API interface
>>  - Move ZGC-specific barrier elision code to BarrierSetC2
>>  - Set UseNewCode to true temporarily
>>  - Make elide_mach_barrier virtual
>>  - Move late barrier elision analysis from G1BarrierSetC2 to BarrierSetC2
>>  - Initial implementation
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/afcc2b03...ab47d7f8
>
> src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 956:
> 
>> 954: static bool is_unknown(intptr_t offset) {
>> 955:   return offset == Type::OffsetBot;
>> 956: }
> 
> pre-existing: these two predicates would be nice to have elsewhere in C2 code too (i.e. there's quite a lot of these predicates inlined elsewhere).

Maybe something for another RFE of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23235#discussion_r1936890465

From tschatzl at openjdk.org  Fri Jan 31 10:03:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 31 Jan 2025 10:03:57 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v3]
In-Reply-To: <JTiEx6zF8THHeo0OSfz38SheTjK8qP0Mh1Ua6SemPqM=.dc9dbaaf-424f-442a-a6af-f57b06e7b6ed@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
 <JTiEx6zF8THHeo0OSfz38SheTjK8qP0Mh1Ua6SemPqM=.dc9dbaaf-424f-442a-a6af-f57b06e7b6ed@github.com>
Message-ID: <8Lb7XeZ9wbZh7Z5p4Dfc2_whwn5a-VUFE8PzRren8Ms=.763589bb-a63c-4844-a26e-95b8e4c34c5f@github.com>

On Thu, 30 Jan 2025 14:59:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of removing the use of `virtual` method and use concrete subclasses when needed.
>> 
>> Test: tier1-5
>
> 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 four commits:
> 
>  - review
>  - Merge branch 'master' into gen-counter
>  - merge
>  - gen-counter

I looked at the change and I recommend additional related refactoring:
* have the `update_all` method of the subclasses call the `update_all(size_t)` method instead of using the `_current_size` (which should probably be called `_cur_capacity`?) to be more OO.
* this allows hiding that member as `private`
* and `_name_space` can also be made `private`

I prepared a commit for such change: https://github.com/openjdk/jdk/commit/331bc9c6e7d0a6402fb627216c1da6d5f6b50c9f

Fwiw, I wouldn't mind renaming `update_all` to `update_capacity` here because it seems trivial anyway.

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

PR Review: https://git.openjdk.org/jdk/pull/23209#pullrequestreview-2586171924

From tschatzl at openjdk.org  Fri Jan 31 10:25:50 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 31 Jan 2025 10:25:50 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v3]
In-Reply-To: <JTiEx6zF8THHeo0OSfz38SheTjK8qP0Mh1Ua6SemPqM=.dc9dbaaf-424f-442a-a6af-f57b06e7b6ed@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
 <JTiEx6zF8THHeo0OSfz38SheTjK8qP0Mh1Ua6SemPqM=.dc9dbaaf-424f-442a-a6af-f57b06e7b6ed@github.com>
Message-ID: <tuOFr-yeM-vxLb3d6YZ8q1k0lEK8GTwE4s0Xm7-Yiz4=.104e5554-fad0-4350-9ada-182a0dc5ed84@github.com>

On Thu, 30 Jan 2025 14:59:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of removing the use of `virtual` method and use concrete subclasses when needed.
>> 
>> Test: tier1-5
>
> 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 four commits:
> 
>  - review
>  - Merge branch 'master' into gen-counter
>  - merge
>  - gen-counter

The `VirtualSpace` forward declaration in `generationCounters.hpp` also seems to be unnecessary.

And there is an extra line between the last method declaration and the closing bracket of the `GenerationCounters` class.

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

PR Comment: https://git.openjdk.org/jdk/pull/23209#issuecomment-2626857362

From ayang at openjdk.org  Fri Jan 31 12:30:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 31 Jan 2025 12:30:30 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v4]
In-Reply-To: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
Message-ID: <bRZ7PVXUDU31NoQxDYS42gmlcvvhBwMn2dxSvZYQH3g=.2c6361ce-cd4e-4909-8014-fe7712ed7c94@github.com>

> Simple refactoring of removing the use of `virtual` method and use concrete subclasses when needed.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:

 - review
 - * some more refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23209/files
  - new: https://git.openjdk.org/jdk/pull/23209/files/b660dd79..13921a7d

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

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

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

From gli at openjdk.org  Fri Jan 31 12:49:47 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 31 Jan 2025 12:49:47 GMT
Subject: RFR: 8348171: Refactor GenerationCounters and its subclasses [v4]
In-Reply-To: <bRZ7PVXUDU31NoQxDYS42gmlcvvhBwMn2dxSvZYQH3g=.2c6361ce-cd4e-4909-8014-fe7712ed7c94@github.com>
References: <F_cpBcdlWdfdzK6GeuuauMLuy2aB-QD42k_Opy4XBl8=.5266c44c-e98b-462f-ac85-29ecfb22db1e@github.com>
 <bRZ7PVXUDU31NoQxDYS42gmlcvvhBwMn2dxSvZYQH3g=.2c6361ce-cd4e-4909-8014-fe7712ed7c94@github.com>
Message-ID: <aFgM7UH5o_aGj4bGU9Ec-SNxb2E8onuK_iDBnSrgDQg=.8c0b9da4-7a54-468f-9f53-eca065b6f179@github.com>

On Fri, 31 Jan 2025 12:30:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of removing the use of `virtual` method and use concrete subclasses when needed.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - * some more refactoring

Marked as reviewed by gli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23209#pullrequestreview-2586564955

From rcastanedalo at openjdk.org  Fri Jan 31 14:02:03 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 31 Jan 2025 14:02:03 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v2]
In-Reply-To: <gD0K0nnWjN5S1njkKZ3rkIT0UKnEbT5KIZpayS8VgVg=.99555536-ec9b-4a4b-97fb-124d4c26d924@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
 <gD0K0nnWjN5S1njkKZ3rkIT0UKnEbT5KIZpayS8VgVg=.99555536-ec9b-4a4b-97fb-124d4c26d924@github.com>
Message-ID: <1wcJkHufgu8uW0IHzcNj8krUnqkOl7N3FihvGUjRfMo=.f1667832-2238-43ce-90f9-1e52b657423e@github.com>

On Fri, 31 Jan 2025 08:53:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roberto Casta?eda Lozano 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 commit 'afcc2b0' into JDK-8346280-late-barrier-elision
>>  - Add new test case (store after exception)
>>  - Remove unused includes
>>  - Remove temporary UseNewCode guard
>>  - Use clearer names and document access API interface
>>  - Move ZGC-specific barrier elision code to BarrierSetC2
>>  - Set UseNewCode to true temporarily
>>  - Make elide_mach_barrier virtual
>>  - Move late barrier elision analysis from G1BarrierSetC2 to BarrierSetC2
>>  - Initial implementation
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/afcc2b03...ab47d7f8
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 570:
> 
>> 568:         }
>> 569:         break;
>> 570:       default:
> 
> ZGC also tries to elide barriers for atomic ops. Why isn't this done for G1 too?

Good question. I simply assumed that it was not safe to elide barriers for atomic operations on newly allocated objects for G1, as it is not for ZGC (see motivation [here](https://github.com/openjdk/jdk/blob/5878e45ae07404bc18518e6a2cb551a7969fddd6/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp#L764-L768)). But on second thought, that motivation seems ZGC-specific. Extending this changeset to elide G1 barriers for atomics that operate on newly allocated objects should be simple, should I do it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23235#discussion_r1937364100

From rcastanedalo at openjdk.org  Fri Jan 31 14:09:43 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 31 Jan 2025 14:09:43 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v3]
In-Reply-To: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
Message-ID: <Q2nuwd7tw__PMdk3y4oqZUzL548IIbZgHmw6bf1sQps=.04b910fe-67c9-42e2-95cc-6b97e4a21e8d@github.com>

> G1 barriers can be safely elided from writes to newly allocated objects as long as no safepoint is taken between the allocation and the write. This changeset complements early G1 barrier elision (performed by the platform-independent phases of C2, and limited to writes immediately following allocations) with a more general elision pass done at a late stage.
> 
> The late elision pass exploits that it runs at a stage where the relative order of memory accesses and safepoints cannot change anymore to elide barriers from initialization writes that do not immediately follow the corresponding allocation, e.g. in conditional initialization writes:
> 
> 
> o = new MyObject();
> if (...) {
>     o.myField = ...;  // barrier elided only after this changeset
>                       // (assuming no safepoint in the if condition)
> }
> 
> 
> or in initialization writes placed after exception-throwing checks:
> 
> 
> o = new MyObject();
> if (...) {
>     throw new Exception("");
> }
> o.myField = ...;  // barrier elided only after this changeset
>                   // (assuming no safepoint in the above if condition)
> 
> 
> These patterns are commonly found in Java code, e.g. in the core libraries:
> 
> - [conditional initialization](https://github.com/openjdk/jdk/blob/25fecaaf87400af535c242fe50296f1f89ceeb16/src/java.base/share/classes/java/lang/String.java#L4850), or
> 
> - [initialization after exception-throwing checks (in the superclass constructor)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L324).
> 
> The optimization also enhances barrier elision for array initialization writes, for example eliding barriers from small array initialization loops (for which safepoints are not inserted):
> 
> 
> Object[] a = new Object[...];
> for (int i = 0; i < a.length; i++) {
>     a[i] = ...;  // barrier elided only after this changeset
> }
> 
> 
> or eliding barriers from array initialization writes with unknown array index:
> 
> 
> Object[] a = new Object[...];
> a[index] = ...;  // barrier elided only after this changeset
> 
> 
> The logic used to perform this additional barrier elision is a subset of a pre-existing ZGC-specific optimization. This changeset simply reuses the relevant subset (barrier elision for writes to newly-allocated objects) by extracting the core of the optimization logic from `zBarrierSetC2.cpp` into the GC-shared file `barrierSetC2.cpp`. The functions `block_has_safepoint`, `block_index`, `look_through_node`, `is_{undefined|unknown|concrete}`, `get_base_and_offset`, `is_array...

Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused declaration (pre-existing)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23235/files
  - new: https://git.openjdk.org/jdk/pull/23235/files/ab47d7f8..3d154fa8

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

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

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

From rcastanedalo at openjdk.org  Fri Jan 31 14:09:44 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 31 Jan 2025 14:09:44 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v2]
In-Reply-To: <gD0K0nnWjN5S1njkKZ3rkIT0UKnEbT5KIZpayS8VgVg=.99555536-ec9b-4a4b-97fb-124d4c26d924@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
 <gD0K0nnWjN5S1njkKZ3rkIT0UKnEbT5KIZpayS8VgVg=.99555536-ec9b-4a4b-97fb-124d4c26d924@github.com>
Message-ID: <XVLeNlbFjYv9CaGr4hziAN9LjlwJDg2f8YAbrIcgMYA=.9454bfe3-5bc0-4d2e-b970-80008b0b0602@github.com>

On Fri, 31 Jan 2025 08:54:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> One question about elision for atomics.
> 
> Otherwise it seems good afaict, although a large part was checking that the code movement is/was correct.

Thanks for reviewing Thomas! Please let me know whether you want me to extend this changeset to elide barriers on atomic operations (happy to do so).

> src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 1048:
> 
>> 1046:     return false;
>> 1047:   }
>> 1048:   const TypePtr* const adr_type = nullptr;
> 
> pre-existing: `adr_type` is unused in the following.

Removed (commit 3d154fa8), thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/23235#issuecomment-2627437036
PR Review Comment: https://git.openjdk.org/jdk/pull/23235#discussion_r1937370541

From rcastanedalo at openjdk.org  Fri Jan 31 14:09:45 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 31 Jan 2025 14:09:45 GMT
Subject: RFR: 8346280: C2: implement late barrier elision for G1 [v2]
In-Reply-To: <TopoY6okYG6ZXRzFixx7ZXEJTvl5YhG1R3Om40StDIQ=.846da9bd-6720-4a2d-9a9e-0087f420962b@github.com>
References: <3eOK-nFYQbKn1w81CWHUY14wk0gyWMT5ULHgZ-ih5-w=.8be51ad0-f412-4aad-b73a-436ccdb8181a@github.com>
 <Nxg81EFT97BvMNSi3QKyU1LgAA9-XAKl1N2zocnIxMo=.c62ce420-0474-42d4-9272-cbd6fb4c4a8b@github.com>
 <gD0K0nnWjN5S1njkKZ3rkIT0UKnEbT5KIZpayS8VgVg=.99555536-ec9b-4a4b-97fb-124d4c26d924@github.com>
 <TopoY6okYG6ZXRzFixx7ZXEJTvl5YhG1R3Om40StDIQ=.846da9bd-6720-4a2d-9a9e-0087f420962b@github.com>
Message-ID: <iqYSA7IZXZXCHlkEB1ABkZ5STNyOaCt-7-6S9rdnC6k=.1b6b9471-ed34-4383-96ab-466ba79f3171@github.com>

On Fri, 31 Jan 2025 08:55:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 956:
>> 
>>> 954: static bool is_unknown(intptr_t offset) {
>>> 955:   return offset == Type::OffsetBot;
>>> 956: }
>> 
>> pre-existing: these two predicates would be nice to have elsewhere in C2 code too (i.e. there's quite a lot of these predicates inlined elsewhere).
>
> Maybe something for another RFE of course.

Thanks, this will make a good starter RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23235#discussion_r1937371221