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 coleenp at openjdk.org  Fri Jan  3 14:38:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 14:38:22 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
Message-ID: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>

There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.

Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

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

Commit messages:
 - 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros

Changes: https://git.openjdk.org/jdk/pull/22916/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22916&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346990
  Stats: 339 lines in 83 files changed: 0 ins; 13 del; 326 mod
  Patch: https://git.openjdk.org/jdk/pull/22916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22916/head:pull/22916

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

From jwaters at openjdk.org  Fri Jan  3 15:43:41 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Jan 2025 15:43:41 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <GB7FT__OPX76lA3Ch8Uwjb5So6JcI-K4ZFQ2ox3uC38=.d2072422-4281-418d-beff-cbb16c1afdcb@github.com>

On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Speaking of %z, there is a non Standard %Ix in os_windows.cpp


tty->print_cr("reserve_memory of %Ix bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes,
                    reserveTimer.milliseconds(), reserveTimer.ticks());


Could changing that to %zu be trivial enough to fit into this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2569435948

From coleenp at openjdk.org  Fri Jan  3 16:23:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 16:23:31 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix %Ix to %zx.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/6d6fbfa7..1748797a

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

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

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

From coleenp at openjdk.org  Fri Jan  3 16:23:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 16:23:32 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <PqP9LcFOEMsX5bVeywyEEEdBVvHSp7y6axjHAOgCYIw=.24eb6982-7cb1-4686-a2ba-a6fc0500f80a@github.com>

On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

I was going to take on the other FORMAT ones in separate PRs.
Sorry I see what you're saying.  yes, I'll fix that too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2569484010

From kbarrett at openjdk.org  Sat Jan  4 10:04:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Jan 2025 10:04:46 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
Message-ID: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>

On Fri, 3 Jan 2025 16:23:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix %Ix to %zx.

Uses of `[U]INTX_FORMAT_X` have been replaced with `0x%zx`.  I mentioned the
possibility of instead using `%#zx`.  I don't know if we really want to use some of
the (to me) more obscure flag options though.

src/hotspot/cpu/x86/vm_version_x86.cpp line 1725:

> 1723:         ArrayOperationPartialInlineSize = MaxVectorSize >= 16 ? MaxVectorSize : 0;
> 1724:         if (ArrayOperationPartialInlineSize) {
> 1725:           warning("Setting ArrayOperationPartialInlineSize as MaxVectorSize%zd)", MaxVectorSize);

pre-existing: seems like there should be a separator of some kind between "MaxVectorSize" and the
value, either a space or an "=" would be okay.

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

> 1368: 
> 1369: #define _UFM "%zu"
> 1370: #define _DFM "%zd"

Why not get rid of these?

src/hotspot/share/ci/ciMethodData.cpp line 788:

> 786:     // which makes comparing it with the SA version of this output
> 787:     // harder. data()'s element type is intptr_t.
> 788:     out->print(" 0x%zx", data()[i]);

Could instead use " %#zx".

src/hotspot/share/compiler/disassembler.cpp line 600:

> 598:         st->print("Stub::%s", desc->name());
> 599:         if (desc->begin() != adr) {
> 600:           st->print("%+zd " PTR_FORMAT, adr - desc->begin(), p2i(adr));

Oh, that's an interesting "abuse" of the `_W` variant.

src/hotspot/share/gc/shared/ageTable.cpp line 38:

> 36: #include "logging/logStream.hpp"
> 37: 
> 38: /* Copyright (c) 1992, 2025, Oracle and/or its affiliates, and Stanford University.

Well this is weird.  An atypical copyright down inside the file?

src/hotspot/share/oops/instanceKlass.cpp line 3695:

> 3693: 
> 3694:   st->print(BULLET"hash_slot:         %d", hash_slot()); st->cr();
> 3695:   st->print(BULLET"secondary bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap); st->cr();

Should be using "zx" rather than "zu".   I think this could be written as 
`"%#0*zx", (2 * BytesPerWord + 2), _secondary_supers_bitmap`
That's looking a lot like line noise though.  I think this and ones like it probably ought not be
changed at all.

src/hotspot/share/oops/klass.cpp line 1308:

> 1306:   if (secondary_supers() != nullptr) {
> 1307:     st->print("  - "); st->print("%d elements;", _secondary_supers->length());
> 1308:     st->print_cr(" bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap);

Same as in instanceKlass - maybe this shouldn't be changed at all.

src/hotspot/share/utilities/globalDefinitions.hpp line 156:

> 154: #define UINTX_FORMAT_X_0         "0x%016"     PRIxPTR
> 155: #else
> 156: #define UINTX_FORMAT_X_0         "0x%08"      PRIxPTR

As noted in places where it's used, I'm not sure we should remove and replace UINTX_FORMAT_X_0.

test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 281:

> 279: 
> 280:   check_format("%zd",                  (intx)123,         "123");
> 281:   check_format("0x%zx",                (intx)0x123,       "0x123");

Could be "%#zx".

test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 286:

> 284: 
> 285:   check_format("%zu",                  (uintx)123u,       "123");
> 286:   check_format("0x%zx",                (uintx)0x123u,     "0x123");

Could be "%#zx".

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2530503795
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902879593
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902886743
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902972028
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902912020
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902916165
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902944144
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902945394
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902960940
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902965078
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902966477

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 shade at openjdk.org  Mon Jan  6 12:05:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Jan 2025 12:05:12 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
Message-ID: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>

**NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**

My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.

This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.

Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.

The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.

x86_32 is the only platform that has special cases for x87 FPU.

C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.

Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.

x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.

The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainline, so I would like to do it separately as the follow-up.

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

Commit messages:
 - More cleanups/reversals
 - More FPU cleanups in C1 regalloc
 - More touchups
 - Fix more backsliding LP64 in Assembler
 - Revert accidental removal in C1 regalloc
 - C1: Cleanup dead lir_f stack ops
 - Cleanup more FPU-related stuff
 - Remove rounding code from C1 and template interpreter
 - Purge 32-bit specific rounding mode
 - OS cleanup
 - ... and 9 more: https://git.openjdk.org/jdk/compare/f1d85ab3...b55fc750

Changes: https://git.openjdk.org/jdk/pull/22567/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345169
  Stats: 40692 lines in 213 files changed: 33 ins; 39906 del; 753 mod
  Patch: https://git.openjdk.org/jdk/pull/22567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22567/head:pull/22567

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

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 coleenp at openjdk.org  Mon Jan  6 15:09:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:09:18 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v3]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <v-l_S89jSVDIGrgoEHbJG3MGPELL_w4CYjPS2vE7lFc=.6a1fb33c-f2ba-48c6-a3d1-fe4463a492dd@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fixed some code review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/1748797a..15b1052a

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

  Stats: 16 lines in 5 files changed: 0 ins; 9 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22916/head:pull/22916

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

From coleenp at openjdk.org  Mon Jan  6 15:09:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:09:19 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
Message-ID: <3vQ-kxRahCEhGLRshu6KE_0ZkWCnrgtnyx8cbXsPIeE=.24a34a54-28b0-4202-8ea3-6bd2b7325ce3@github.com>

On Fri, 3 Jan 2025 16:23:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix %Ix to %zx.

Kim, thanks for slogging through this change.  I've updated the patch with your suggested changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2573301941

From coleenp at openjdk.org  Mon Jan  6 15:09:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:09:19 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
Message-ID: <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>

On Sat, 4 Jan 2025 09:02:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix %Ix to %zx.
>
> src/hotspot/os/linux/os_linux.cpp line 1370:
> 
>> 1368: 
>> 1369: #define _UFM "%zu"
>> 1370: #define _DFM "%zd"
> 
> Why not get rid of these?

Fixed.

> src/hotspot/share/gc/shared/ageTable.cpp line 38:
> 
>> 36: #include "logging/logStream.hpp"
>> 37: 
>> 38: /* Copyright (c) 1992, 2025, Oracle and/or its affiliates, and Stanford University.
> 
> Well this is weird.  An atypical copyright down inside the file?

This is a relic and not the legal copyright that got updated since nobody noticed.  Until you did.  Removed.

> src/hotspot/share/oops/instanceKlass.cpp line 3695:
> 
>> 3693: 
>> 3694:   st->print(BULLET"hash_slot:         %d", hash_slot()); st->cr();
>> 3695:   st->print(BULLET"secondary bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap); st->cr();
> 
> Should be using "zx" rather than "zu".   I think this could be written as 
> `"%#0*zx", (2 * BytesPerWord + 2), _secondary_supers_bitmap`
> That's looking a lot like line noise though.  I think this and ones like it probably ought not be
> changed at all.

I have to confess that I have no idea what this is trying to show.  I'd rather have all the UINTX_FORMAT purged and not leave a remnant for these two special cases.  A function whose name describes what this is trying to show would be better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904264225
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904264062
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904263162

From coleenp at openjdk.org  Mon Jan  6 15:24:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:24:18 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v4]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <TL-PdaGpWb-cAJFmKJrMKkNy1L5wkbFZFxU1Kt0_KkY=.d541d19d-0014-4be1-88c5-fab6e1f76c3b@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Use INTPTR_FORMAT instead of zu for secondary_supers_bitmap.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/15b1052a..6e8b2702

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

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

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

From coleenp at openjdk.org  Mon Jan  6 15:24:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:24:19 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
Message-ID: <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>

On Mon, 6 Jan 2025 15:03:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 3695:
>> 
>>> 3693: 
>>> 3694:   st->print(BULLET"hash_slot:         %d", hash_slot()); st->cr();
>>> 3695:   st->print(BULLET"secondary bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap); st->cr();
>> 
>> Should be using "zx" rather than "zu".   I think this could be written as 
>> `"%#0*zx", (2 * BytesPerWord + 2), _secondary_supers_bitmap`
>> That's looking a lot like line noise though.  I think this and ones like it probably ought not be
>> changed at all.
>
> I have to confess that I have no idea what this is trying to show.  I'd rather have all the UINTX_FORMAT purged and not leave a remnant for these two special cases.  A function whose name describes what this is trying to show would be better.

@theRealAph added this with the secondary super cache work, but I think it may have also been meant to be zx because of the leading 0x.  So INTPTR_FORMAT would also work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904284828

From coleenp at openjdk.org  Mon Jan  6 16:02:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 16:02:36 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
Message-ID: <XNMHk0Rh8KL4VxuqCHjK7agSagK9tG2hgXWm1_l8lEg=.72ef1aa2-5d33-4add-93af-291c969c418f@github.com>

On Sat, 4 Jan 2025 09:52:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix %Ix to %zx.
>
> test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 281:
> 
>> 279: 
>> 280:   check_format("%zd",                  (intx)123,         "123");
>> 281:   check_format("0x%zx",                (intx)0x123,       "0x123");
> 
> Could be "%#zx".

I fixed this.  This seems ok.  I didn't know about this format option tbh but if it's standard, why not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904331779

From kvn at openjdk.org  Mon Jan  6 17:49:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 6 Jan 2025 17:49:41 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <OqTXjfuLeIUD5nqAmvpWrg9j3BeoiEYIDYo6eLRXNOw=.ac26d63d-2b17-4922-86d3-611e89d357df@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

> The one thing I deliberately avoided doing is merging x86.ad and x86_64.ad.

I think we can keep them separate (big .ad files is difficult to navigate). `x86.ad` is mostly used for vector instructions. We can rename it to ``x86_vect.ad`. And `x86_64.ad` to `x86.ad`. As followup changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2573606824

From kvn at openjdk.org  Mon Jan  6 17:53:35 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 6 Jan 2025 17:53:35 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <dBWI2eJzlouB0kRQK7prMGpBggiV4qoVyHWt5GEW5Wo=.4667adc1-75f9-41b3-bd9e-193cfb6fb186@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

I don't see make files changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2573613772

From kvn at openjdk.org  Mon Jan  6 18:01:50 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 6 Jan 2025 18:01:50 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <go_2UNDvI1vayb7ZtNRLArUlXTunyywmKuwG0PeqGuY=.d922b540-7ef6-486a-8a4b-18accf6d2176@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

It would be nice to split this into separate PRs for easy review. Removing "rounding of x87 FPU" could be definitely done separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2573626448

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 dholmes at openjdk.org  Tue Jan  7 06:24:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 06:24:41 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

src/hotspot/share/interpreter/abstractInterpreter.cpp line 137:

> 135:       case vmIntrinsics::_floatToRawIntBits: return java_lang_Float_floatToRawIntBits;
> 136:       case vmIntrinsics::_longBitsToDouble:  return java_lang_Double_longBitsToDouble;
> 137:       case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits;

Why are these intrinsics for the Java methods disappearing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1904957718

From kbarrett at openjdk.org  Tue Jan  7 08:34:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:34:41 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
Message-ID: <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>

On Mon, 6 Jan 2025 15:04:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/ageTable.cpp line 38:
>> 
>>> 36: #include "logging/logStream.hpp"
>>> 37: 
>>> 38: /* Copyright (c) 1992, 2025, Oracle and/or its affiliates, and Stanford University.
>> 
>> Well this is weird.  An atypical copyright down inside the file?
>
> This is a relic and not the legal copyright that got updated since nobody noticed.  Until you did.  Removed.

Not sure we're allowed to remove a copyright statement, even if not in the usual place.

>> test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 281:
>> 
>>> 279: 
>>> 280:   check_format("%zd",                  (intx)123,         "123");
>>> 281:   check_format("0x%zx",                (intx)0x123,       "0x123");
>> 
>> Could be "%#zx".
>
> I fixed this.  This seems ok.  I didn't know about this format option tbh but if it's standard, why not?

I'd forgotten about that format option too, which is why I'm not enamored of it.  Also, written that way the
prefix gets included in the width when dealing with field width, which might not be great either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905081061
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905079637

From kbarrett at openjdk.org  Tue Jan  7 08:34:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:34:42 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
Message-ID: <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>

On Mon, 6 Jan 2025 15:21:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I have to confess that I have no idea what this is trying to show.  I'd rather have all the UINTX_FORMAT purged and not leave a remnant for these two special cases.  A function whose name describes what this is trying to show would be better.
>
> @theRealAph added this with the secondary super cache work, but I think it may have also been meant to be zx because of the leading 0x.  So INTPTR_FORMAT would also work.

I don't think we should be mixing uintx types and UINTPTR_FORMAT like that.  As I said earlier, this is one that
I think probably ought not be changed at all.  I think some of the FORMAT macros are useful to avoid inline
format directives that resemble line noise, or ugly conditionals like that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905076840

From kbarrett at openjdk.org  Tue Jan  7 08:52:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:52:42 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
 <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>
Message-ID: <BuoklO2QXoFY_QGV-XGSIyx1fjKDzvfAIKnSX23voB4=.32964bc7-a214-4ee4-9925-b327aa900c8f@github.com>

On Tue, 7 Jan 2025 08:28:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @theRealAph added this with the secondary super cache work, but I think it may have also been meant to be zx because of the leading 0x.  So INTPTR_FORMAT would also work.
>
> I don't think we should be mixing uintx types and UINTPTR_FORMAT like that.  As I said earlier, this is one that
> I think probably ought not be changed at all.  I think some of the FORMAT macros are useful to avoid inline
> format directives that resemble line noise, or ugly conditionals like that.

Improving on my prior suggestion
`"%#.*zx", (2 * BytesPerWord), _secondary_supers_bitmap`
Using precision rather than field width, to avoid needing to account for the prefix in the width calculation.
But still looking a lot like line noise, and still think it shouldn't be changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905101674

From kbarrett at openjdk.org  Tue Jan  7 08:52:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:52:43 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
Message-ID: <esnDP-9AzRwztBz2v7Eu_ndX6yU652c8SJQ8we_-NLg=.995481e6-6751-4501-9fee-dc6c0c228934@github.com>

On Tue, 7 Jan 2025 08:31:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I fixed this.  This seems ok.  I didn't know about this format option tbh but if it's standard, why not?
>
> I'd forgotten about that format option too, which is why I'm not enamored of it.  Also, written that way the
> prefix gets included in the width when dealing with field width, which might not be great either.

The problem of accounting for the prefix in the field width calculation can be dealt with by using precision
rather than field width.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905104428

From shade at openjdk.org  Tue Jan  7 09:15:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Jan 2025 09:15:41 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
Message-ID: <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>

On Tue, 7 Jan 2025 06:21:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
>> 
>> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
>> 
>> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
>> 
>> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
>> 
>> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
>> 
>> x86_32 is the only platform that has special cases for x87 FPU.
>> 
>> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
>> 
>> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
>> 
>> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
>> 
>> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of...
>
> src/hotspot/share/interpreter/abstractInterpreter.cpp line 137:
> 
>> 135:       case vmIntrinsics::_floatToRawIntBits: return java_lang_Float_floatToRawIntBits;
>> 136:       case vmIntrinsics::_longBitsToDouble:  return java_lang_Double_longBitsToDouble;
>> 137:       case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits;
> 
> Why are these intrinsics for the Java methods disappearing?

These are interpreter "intrinsics" that are only implemented on x86_32 to handle x87 FPU pecularities. Look around for `TemplateInterpreterGenerator::generate_Float_intBitsToFloat_entry`, for example.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1905134973

From coleenp at openjdk.org  Tue Jan  7 12:36:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:36:46 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <esnDP-9AzRwztBz2v7Eu_ndX6yU652c8SJQ8we_-NLg=.995481e6-6751-4501-9fee-dc6c0c228934@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
 <esnDP-9AzRwztBz2v7Eu_ndX6yU652c8SJQ8we_-NLg=.995481e6-6751-4501-9fee-dc6c0c228934@github.com>
Message-ID: <ThBA0Kns0IoLwZ4OkKm5X_oh5WJKcgGn_AV610Xhhyo=.c65e531d-5c24-438d-8b09-498f40235f6e@github.com>

On Tue, 7 Jan 2025 08:50:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I'd forgotten about that format option too, which is why I'm not enamored of it.  Also, written that way the
>> prefix gets included in the width when dealing with field width, which might not be great either.
>
> The problem of accounting for the prefix in the field width calculation can be dealt with by using precision
> rather than field width.

Well then that leaves the fun of dealing with these format specifiers when you're trying to do your own formatting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905390045

From coleenp at openjdk.org  Tue Jan  7 12:51:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:51:33 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Restore copyright and macro.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/6e8b2702..ae9d9f6f

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

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

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

From coleenp at openjdk.org  Tue Jan  7 12:51:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:51:33 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <BuoklO2QXoFY_QGV-XGSIyx1fjKDzvfAIKnSX23voB4=.32964bc7-a214-4ee4-9925-b327aa900c8f@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
 <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>
 <BuoklO2QXoFY_QGV-XGSIyx1fjKDzvfAIKnSX23voB4=.32964bc7-a214-4ee4-9925-b327aa900c8f@github.com>
Message-ID: <L3cRMsD-8R7vI4fAvbYGrkjq6xEOrpjvrMMIGjZboFY=.67be8877-242a-47c9-b224-5829ce85eab7@github.com>

On Tue, 7 Jan 2025 08:48:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I don't think we should be mixing uintx types and UINTPTR_FORMAT like that.  As I said earlier, this is one that
>> I think probably ought not be changed at all.  I think some of the FORMAT macros are useful to avoid inline
>> format directives that resemble line noise, or ugly conditionals like that.
>
> Improving on my prior suggestion
> `"%#.*zx", (2 * BytesPerWord), _secondary_supers_bitmap`
> Using precision rather than field width, to avoid needing to account for the prefix in the width calculation.
> But still looking a lot like line noise, and still think it shouldn't be changed.

Yes, this looks horrible.  The macro that I was trying to remove is better.  I restored but moved it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905405696

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 dholmes at openjdk.org  Thu Jan  9 01:21:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Jan 2025 01:21:15 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
 <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>
Message-ID: <YBl0QWTX01LYMxsH7mOrFVfRJDUOl0PJErdyO5VA9Ow=.9dd25af9-c4df-4a38-bf79-d1bf88155edc@github.com>

On Tue, 7 Jan 2025 09:13:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/interpreter/abstractInterpreter.cpp line 137:
>> 
>>> 135:       case vmIntrinsics::_floatToRawIntBits: return java_lang_Float_floatToRawIntBits;
>>> 136:       case vmIntrinsics::_longBitsToDouble:  return java_lang_Double_longBitsToDouble;
>>> 137:       case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits;
>> 
>> Why are these intrinsics for the Java methods disappearing?
>
> These are interpreter "intrinsics" that are only implemented on x86_32 to handle x87 FPU pecularities. Look around for `TemplateInterpreterGenerator::generate_Float_intBitsToFloat_entry`, for example.

Hmmm ... okay ... I see something "special" is done only on x86_32, but what is done seems to have nothing to do with x87 code.

Just to be clear these Java methods still get intrinsified, it is just handled in a different way - right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1908061750

From shade at openjdk.org  Thu Jan  9 09:38:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Jan 2025 09:38:38 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <YBl0QWTX01LYMxsH7mOrFVfRJDUOl0PJErdyO5VA9Ow=.9dd25af9-c4df-4a38-bf79-d1bf88155edc@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
 <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>
 <YBl0QWTX01LYMxsH7mOrFVfRJDUOl0PJErdyO5VA9Ow=.9dd25af9-c4df-4a38-bf79-d1bf88155edc@github.com>
Message-ID: <SQUEdE1fFiWXLWxBQIDvCikr0Ynw5UP_evoTeNkQdiI=.15525857-a5f9-48fc-b02b-a7e9562a5569@github.com>

On Thu, 9 Jan 2025 01:17:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> These are interpreter "intrinsics" that are only implemented on x86_32 to handle x87 FPU pecularities. Look around for `TemplateInterpreterGenerator::generate_Float_intBitsToFloat_entry`, for example.
>
> Hmmm ... okay ... I see something "special" is done only on x86_32, but what is done seems to have nothing to do with x87 code.
> 
> Just to be clear these Java methods still get intrinsified, it is just handled in a different way - right?

It *is* about x87 handling of NaNs, a common problem for x86_32 code in Hotspot, you can read about this mess in [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373), if you are interested. If we allow to use native implementations of these conversion methods, we get into trouble with NaNs. What these interpreter intrinsics do on x86_32: going for SSE if available, thus avoiding x87. Since this is a correctness problem, these intrinsics go all the way down to interpreter as well. There is still a gaping hole when SSE is not available, but then we have no choice than to use x87 and have all the relevant issues. 

But all of this is only a headache for x86_32, all other platforms do not have these interpreter intrinsics implemented. With x86_32 going away, we can finally yank these and relevant scaffolding out.

The C1/C2 intrinsics are still up and enabled for supported platforms: those are for performance :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1908436596

From coleenp at openjdk.org  Thu Jan  9 13:34:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Jan 2025 13:34:39 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
Message-ID: <wwAwF9ePyVJAORFl1RKLcVEnyngfLST0iQoM-e1-Bh0=.4bbff6a3-9664-4ac3-b6f8-d5ce50d1c2d6@github.com>

On Tue, 7 Jan 2025 08:32:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a relic and not the legal copyright that got updated since nobody noticed.  Until you did.  Removed.
>
> Not sure we're allowed to remove a copyright statement, even if not in the usual place.

put copyright back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1908806441

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: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 matsaave at openjdk.org  Thu Jan  9 19:04:51 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Jan 2025 19:04:51 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <uJRJVx-1cgnpbh7t7yfoncqGEEEbkws2BfWkUFUA7zI=.5e095d4b-0b48-4c3c-a179-e7870d6e61ad@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

>From what I've looked at so far it looks good! I noticed there are several cases where you mix format specifiers with macros. I understand that replacing other macros may not be in the scope of this change but I find it inconsistent in places where we have both. 

I listed out some of the cases below, but if you don't believe this to be necessary you can ignore me.

src/hotspot/os/bsd/os_bsd.cpp line 2527:

> 2525:              "\n\n"
> 2526:              "Do you want to debug the problem?\n\n"
> 2527:              "To debug, run 'gdb /proc/%d/exe %d'; then switch to thread %zd (" INTPTR_FORMAT ")\n"

There is both `%zd` and `INTPTR_FORMAT` in this line. I think it would be more consistent to convert both to format specifiers here.

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

> 5274:                "\n\n"
> 5275:                "Do you want to debug the problem?\n\n"
> 5276:                "To debug, run 'gdb /proc/%d/exe %d'; then switch to thread %zu (" INTPTR_FORMAT ")\n"

Same as above

src/hotspot/os/windows/os_windows.cpp line 533:

> 531:   }
> 532: 
> 533:   log_info(os, thread)("Thread is alive (tid: %zu, stacksize: " SIZE_FORMAT "k).", os::current_thread_id(), thread->stack_size() / K);

Same as above, this time with `SIZE_FORMAT`

src/hotspot/os/windows/os_windows.cpp line 618:

> 616:   thread->set_osthread(osthread);
> 617: 
> 618:   log_info(os, thread)("Thread attached (tid: %zu, stack: "

This line also mixes format specifiers and macros

src/hotspot/os/windows/os_windows.cpp line 3340:

> 3338:     if (Verbose && PrintMiscellaneous) {
> 3339:       reserveTimer.stop();
> 3340:       tty->print_cr("reserve_memory of %zx bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes,

Here too

src/hotspot/share/classfile/classLoaderStats.cpp line 115:

> 113:   Klass* parent_klass = (cls._parent == nullptr ? nullptr : cls._parent->klass());
> 114: 
> 115:   _out->print(INTPTR_FORMAT "  " INTPTR_FORMAT "  " INTPTR_FORMAT "  %6zu  " SIZE_FORMAT_W(8) "  " SIZE_FORMAT_W(8) "  ",

Here too

src/hotspot/share/classfile/classLoaderStats.cpp line 126:

> 124:   _out->cr();
> 125:   if (cls._hidden_classes_count > 0) {
> 126:     _out->print_cr(SPACE SPACE SPACE "                                    %6zu  " SIZE_FORMAT_W(8) "  " SIZE_FORMAT_W(8) "   + hidden classes",

And here

src/hotspot/share/classfile/classLoaderStats.cpp line 140:

> 138:   _out->print("Total = %-6zu", _total_loaders);
> 139:   _out->print(SPACE SPACE SPACE "                      ", "", "", "");
> 140:   _out->print_cr("%6zu  " SIZE_FORMAT_W(8) "  " SIZE_FORMAT_W(8) "  ",

And here

src/hotspot/share/code/vtableStubs.cpp line 82:

> 80: 
> 81: void VtableStub::print_on(outputStream* st) const {
> 82:   st->print("vtable stub (index = %d, receiver_location = %zd, code = [" INTPTR_FORMAT ", " INTPTR_FORMAT "])",

And here

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

Changes requested by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2540706941
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909299619
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909300550
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909300883
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909301552
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909301678
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303066
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303216
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303480
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303991

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 coleenp at openjdk.org  Thu Jan  9 20:39:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Jan 2025 20:39:41 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <3rsYHTsq8K_5SIPzeMJQJFM6HMWNTz7OdCBgVBwUUD8=.f3b67c30-8ecb-4034-b0b7-8396c5f8b531@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

The intention is to keep INTPTR_FORMAT and some of the other format specifiers that vary by platform.  I have another issue to remove the SIZE_FORMAT ones but that's a bigger change.  So this mixture is intentional.

JLONG_FORMAT might be something we can remove too but I didn't want to do it all at once.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2581199763

From matsaave at openjdk.org  Thu Jan  9 21:52:47 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Jan 2025 21:52:47 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <2NN6jS-4TNxlwq8K0ovl2o9A3ZdCsTVJJ6NcOWDh-P8=.069b6da4-4c08-4cc6-9532-2b1f96a1793a@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

Looks good! I saw the discussion on `UINTPTR_FORMAT_X_0` so I left it alone.

src/hotspot/share/runtime/objectMonitor.cpp line 2500:

> 2498:   // The minimal things to print for markWord printing, more can be added for debugging and logging.
> 2499:   st->print("{contentions=0x%08x,waiters=0x%08x"
> 2500:             ",recursions=%zd,owner=" INT64_FORMAT "}",

Is `INT64_FORMAT` different from `INTX_FORMAT`?

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2540981143
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909469703

From kbarrett at openjdk.org  Thu Jan  9 22:00:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 22:00:59 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <2NN6jS-4TNxlwq8K0ovl2o9A3ZdCsTVJJ6NcOWDh-P8=.069b6da4-4c08-4cc6-9532-2b1f96a1793a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
 <2NN6jS-4TNxlwq8K0ovl2o9A3ZdCsTVJJ6NcOWDh-P8=.069b6da4-4c08-4cc6-9532-2b1f96a1793a@github.com>
Message-ID: <B6oyiuXbdW78wAwUKpFINC4wUo5MUZluKK5LkFwAbSQ=.9488e486-cc73-4f9e-ac86-08be39c525e2@github.com>

On Thu, 9 Jan 2025 21:47:47 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore copyright and macro.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 2500:
> 
>> 2498:   // The minimal things to print for markWord printing, more can be added for debugging and logging.
>> 2499:   st->print("{contentions=0x%08x,waiters=0x%08x"
>> 2500:             ",recursions=%zd,owner=" INT64_FORMAT "}",
> 
> Is `INT64_FORMAT` different from `INTX_FORMAT`?

Currently yes.  The type underlying [u]intx varies by platform, being a 32-bit type on 32-bit platforms and a
64-bit type on 64-bit platforms.  We've been trimming the set of supported 32-bit platforms though, so maybe
someday we won't need that distinction any more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909478987

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 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 dholmes at openjdk.org  Fri Jan 10 07:21:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Jan 2025 07:21:42 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <SQUEdE1fFiWXLWxBQIDvCikr0Ynw5UP_evoTeNkQdiI=.15525857-a5f9-48fc-b02b-a7e9562a5569@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
 <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>
 <YBl0QWTX01LYMxsH7mOrFVfRJDUOl0PJErdyO5VA9Ow=.9dd25af9-c4df-4a38-bf79-d1bf88155edc@github.com>
 <SQUEdE1fFiWXLWxBQIDvCikr0Ynw5UP_evoTeNkQdiI=.15525857-a5f9-48fc-b02b-a7e9562a5569@github.com>
Message-ID: <x8JmNju6MP1KzBu2TFMnCJ5H7ncBnJl4x37_H6495-I=.36e13324-6bcd-4f4a-8c7d-62811564eea9@github.com>

On Thu, 9 Jan 2025 09:36:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hmmm ... okay ... I see something "special" is done only on x86_32, but what is done seems to have nothing to do with x87 code.
>> 
>> Just to be clear these Java methods still get intrinsified, it is just handled in a different way - right?
>
> It *is* about x87 handling of NaNs, a common problem for x86_32 code in Hotspot, you can read about this mess in [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373), if you are interested. If we allow to use native implementations of these conversion methods, we get into trouble with NaNs. What these interpreter intrinsics do on x86_32: going for SSE if available, thus avoiding x87. Since this is a correctness problem, these intrinsics go all the way down to interpreter as well. There is still a gaping hole when SSE is not available, but then we have no choice than to use x87 and have all the relevant issues. 
> 
> But all of this is only a headache for x86_32, all other platforms do not have these interpreter intrinsics implemented. With x86_32 going away, we can finally yank these and relevant scaffolding out.
> 
> The C1/C2 intrinsics are still up and enabled for supported platforms: those are for performance :)

Okay now I get. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1909928264

From coleenp at openjdk.org  Fri Jan 10 12:57:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Jan 2025 12:57:51 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
Message-ID: <r_LpVoELuStl0SNSzjpRLO2q9UxluZ0pbSb1zt6V1Z4=.1705d0d1-f485-46e8-a7b9-4eb75619a643@github.com>

On Sat, 4 Jan 2025 09:41:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix %Ix to %zx.
>
> src/hotspot/share/oops/klass.cpp line 1308:
> 
>> 1306:   if (secondary_supers() != nullptr) {
>> 1307:     st->print("  - "); st->print("%d elements;", _secondary_supers->length());
>> 1308:     st->print_cr(" bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap);
> 
> Same as in instanceKlass - maybe this shouldn't be changed at all.

I restored this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1910340969

From coleenp at openjdk.org  Fri Jan 10 13:32:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Jan 2025 13:32:40 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

I reviewed the template interpreter changes. They look great.

src/hotspot/cpu/x86/templateTable_x86.cpp line 330:

> 328: void TemplateTable::dconst(int value) {
> 329:   transition(vtos, dtos);
> 330:   if (UseSSE >= 2) {

I admit that I don't know what UseSSE is but now this is unconditional?  Is there a further cleanup necessary for this option?

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

PR Review: https://git.openjdk.org/jdk/pull/22567#pullrequestreview-2542434532
PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910374250

From shade at openjdk.org  Fri Jan 10 13:57:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 13:57:46 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
Message-ID: <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>

On Fri, 10 Jan 2025 13:23:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
>> 
>> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
>> 
>> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
>> 
>> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
>> 
>> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
>> 
>> x86_32 is the only platform that has special cases for x87 FPU.
>> 
>> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
>> 
>> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
>> 
>> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
>> 
>> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of...
>
> src/hotspot/cpu/x86/templateTable_x86.cpp line 330:
> 
>> 328: void TemplateTable::dconst(int value) {
>> 329:   transition(vtos, dtos);
>> 330:   if (UseSSE >= 2) {
> 
> I admit that I don't know what UseSSE is but now this is unconditional?  Is there a further cleanup necessary for this option?

Yes, now it is unconditional. x86_64 [requires](https://github.com/openjdk/jdk/blob/ec7393e9190c1b93ca08e1107f734c869f400b89/src/hotspot/cpu/x86/vm_version_x86.cpp#L896-L903) UseSSE >= 2. Only x86_32 cared about UseSSE < 2, so now we can eliminate these checks. I think I got the majority, if not all of the cases where these checks are now redundant: there are more in various assemblers and compiler code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910408581

From coleenp at openjdk.org  Fri Jan 10 16:24:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Jan 2025 16:24:47 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
Message-ID: <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>

On Fri, 10 Jan 2025 13:54:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/cpu/x86/templateTable_x86.cpp line 330:
>> 
>>> 328: void TemplateTable::dconst(int value) {
>>> 329:   transition(vtos, dtos);
>>> 330:   if (UseSSE >= 2) {
>> 
>> I admit that I don't know what UseSSE is but now this is unconditional?  Is there a further cleanup necessary for this option?
>
> Yes, now it is unconditional. x86_64 [requires](https://github.com/openjdk/jdk/blob/ec7393e9190c1b93ca08e1107f734c869f400b89/src/hotspot/cpu/x86/vm_version_x86.cpp#L896-L903) UseSSE >= 2. Only x86_32 cared about UseSSE < 2, so now we can eliminate these checks. I think I got the majority, if not all of the cases where these checks are now redundant: there are more in various assemblers and compiler code.

Maybe this should change from range (2,4) then.
  product(int, UseSSE, 4,                                                   \
          "Highest supported SSE instructions set on x86/x64")              \
          range(0, 4)                                                       \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910614336

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 ihse at openjdk.org  Fri Jan 10 17:17:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 10 Jan 2025 17:17:46 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <O_VOLucblf3jOEpsqa4f9s_eyW57wGm_5E9BMhHuGKc=.97f30eb1-3ba2-458f-9e2a-59fd1e9c44d5@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

Don't forget the 32-bit x86 classes under `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot`. There might be other x86-specific code in other JDK libraries as well, and not just in Hotspot.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2583294294

From shade at openjdk.org  Fri Jan 10 18:23:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 18:23:49 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
Message-ID: <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>

On Fri, 10 Jan 2025 16:22:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, now it is unconditional. x86_64 [requires](https://github.com/openjdk/jdk/blob/ec7393e9190c1b93ca08e1107f734c869f400b89/src/hotspot/cpu/x86/vm_version_x86.cpp#L896-L903) UseSSE >= 2. Only x86_32 cared about UseSSE < 2, so now we can eliminate these checks. I think I got the majority, if not all of the cases where these checks are now redundant: there are more in various assemblers and compiler code.
>
> Maybe this should change from range (2,4) then.
>   product(int, UseSSE, 4,                                                   \
>           "Highest supported SSE instructions set on x86/x64")              \
>           range(0, 4)                                                       \

Right. Now that I am thinking more deeply about it, maybe that would be a first step here: lift UseSSE >= 2 for x86_32 ahead of this JEP, eliminate all UseSSE < 2 parts. I can see how intrusive this gets.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910843574

From kbarrett at openjdk.org  Fri Jan 10 18:33:47 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Jan 2025 18:33:47 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
 <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
Message-ID: <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>

On Fri, 10 Jan 2025 18:21:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Maybe this should change from range (2,4) then.
>>   product(int, UseSSE, 4,                                                   \
>>           "Highest supported SSE instructions set on x86/x64")              \
>>           range(0, 4)                                                       \
>
> Right. Now that I am thinking more deeply about it, maybe that would be a first step here: lift UseSSE >= 2 for x86_32 ahead of this JEP, eliminate all UseSSE < 2 parts. I can see how intrusive this gets.

[not reviewing, just a drive-by comment] Does UseSSE < 2 provide a way to _avoid_ using relevant parts of
SSE on x86_64, perhaps for debugging?  Or does x86_64 effectively hard-wire UseSSE >= 2?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910878630

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 kvn at openjdk.org  Fri Jan 10 20:28:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 10 Jan 2025 20:28:49 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
 <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
 <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>
Message-ID: <n1T3-oYkjfqOI26aGnecypZ_WE-bAAHLD9f7UTBxQ9Q=.ac3db5ba-06b9-4c1e-b871-361210d0cc38@github.com>

On Fri, 10 Jan 2025 18:30:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Right. Now that I am thinking more deeply about it, maybe that would be a first step here: lift UseSSE >= 2 for x86_32 ahead of this JEP, eliminate all UseSSE < 2 parts. I can see how intrusive this gets.
>
> [not reviewing, just a drive-by comment] Does UseSSE < 2 provide a way to _avoid_ using relevant parts of
> SSE on x86_64, perhaps for debugging?  Or does x86_64 effectively hard-wire UseSSE >= 2?

By default all 64-bits x86 CPU (starting from AMD64) supports all instructions up to SSE2. 32-bit x86 CPU may not support SSE2.

We can generated sse1 or use FPU instructions in 64-bit VM but we decided not to do that -  SSE2 instructions version were much easier to use. We purged all uses of FPU in JDK 15: [JDK-7175279](https://bugs.openjdk.org/browse/JDK-7175279) by using SSE set of instructions because we did not want to mess (save/restore state) with FPU anymore in 64-bit VM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1911258635

From vlivanov at openjdk.org  Fri Jan 10 20:28:49 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 10 Jan 2025 20:28:49 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <e5dZJ-8ac5OI13uat___OEjV2_dm6318ZNAwyjcv07I=.80ba1613-c5fe-4fcf-a133-ffaf85792c2d@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

Personally, I'd prefer to see initial x86-32 removal changeset as straighforward as possible: x86-32-specific files, plus (optionally) x86-32-specific code in x86-specific files.

IMO it's better to cover the rest (getting rid of unused features after x86-32 removal) as follow-up cleanups.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2584013803

From kvn at openjdk.org  Fri Jan 10 20:33:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 10 Jan 2025 20:33:46 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <n1T3-oYkjfqOI26aGnecypZ_WE-bAAHLD9f7UTBxQ9Q=.ac3db5ba-06b9-4c1e-b871-361210d0cc38@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
 <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
 <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>
 <n1T3-oYkjfqOI26aGnecypZ_WE-bAAHLD9f7UTBxQ9Q=.ac3db5ba-06b9-4c1e-b871-361210d0cc38@github.com>
Message-ID: <L1phFk81yC2_neRh6doHpgXem1gI9o0WvZ11bK5uRLc=.ac76ed96-e35d-408c-befa-856742f2a2ad@github.com>

On Fri, 10 Jan 2025 20:23:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [not reviewing, just a drive-by comment] Does UseSSE < 2 provide a way to _avoid_ using relevant parts of
>> SSE on x86_64, perhaps for debugging?  Or does x86_64 effectively hard-wire UseSSE >= 2?
>
> By default all 64-bits x86 CPU (starting from AMD64) supports all instructions up to SSE2. 32-bit x86 CPU may not support SSE2.
> 
> We can generated sse1 or use FPU instructions in 64-bit VM but we decided not to do that -  SSE2 instructions version were much easier to use. We purged all uses of FPU in JDK 15: [JDK-7175279](https://bugs.openjdk.org/browse/JDK-7175279) by using SSE set of instructions because we did not want to mess (save/restore state) with FPU anymore in 64-bit VM.

I think there are several places in 64-bit VM where we assume SSE2 instructions are always available.
So if you set `UseSSE=1 or = 0` in debugger VM may crash.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1911279275

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 kbarrett at openjdk.org  Sat Jan 11 14:11:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 11 Jan 2025 14:11:48 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <0T6dqXyqum7hEpCvg97-WsP_zVfOO9JkBCnze1f3sxE=.9b5c6ba1-9f58-4e74-bee8-5478809216cc@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2544851802

From coleenp at openjdk.org  Sat Jan 11 15:29:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 11 Jan 2025 15:29:48 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <L1phFk81yC2_neRh6doHpgXem1gI9o0WvZ11bK5uRLc=.ac76ed96-e35d-408c-befa-856742f2a2ad@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
 <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
 <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>
 <n1T3-oYkjfqOI26aGnecypZ_WE-bAAHLD9f7UTBxQ9Q=.ac3db5ba-06b9-4c1e-b871-361210d0cc38@github.com>
 <L1phFk81yC2_neRh6doHpgXem1gI9o0WvZ11bK5uRLc=.ac76ed96-e35d-408c-befa-856742f2a2ad@github.com>
Message-ID: <X2SBabT6-X1s2RECVr3P90h__wCsdYr_94Ni_fT3oyo=.1a5070cc-63fc-4b5c-830f-c1f2b2168c4c@github.com>

On Fri, 10 Jan 2025 20:30:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> By default all 64-bits x86 CPU (starting from AMD64) supports all instructions up to SSE2. 32-bit x86 CPU may not support SSE2.
>> 
>> We can generated sse1 or use FPU instructions in 64-bit VM but we decided not to do that -  SSE2 instructions version were much easier to use. We purged all uses of FPU in JDK 15: [JDK-7175279](https://bugs.openjdk.org/browse/JDK-7175279) by using SSE set of instructions because we did not want to mess (save/restore state) with FPU anymore in 64-bit VM.
>
> I think there are several places in 64-bit VM where we assume SSE2 instructions are always available.
> So if you set `UseSSE=1 or = 0` in debugger VM may crash.

Having some kind of pre-JEP patch for this this might be helpful so that we don't drill down on this rather than the whole patch.  Maybe the JEP patch could simply be what @iwanowww  suggests.  Then have a post-JEP patch to remove everything else.  Sort of like what we did with Security Manager.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1912067239

From dholmes at openjdk.org  Mon Jan 13 05:05:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 05:05:49 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <z6KX0QT-sCHVU0qxP9FANjzknbPOXPi8X-wNzGqDZO4=.ebcb8ad4-f9e2-4d46-abff-e7aec4f3c8da@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

Sorry for a "dumb" question but `%z` is for size_t arguments, so why are we using it to replace INTX/UINTX_FORMAT ??? I get that size_t and intx happen to be the same size but still ... if I see  `%z` I expect to see a size_t argument passed in.

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

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2545711471

From coleenp at openjdk.org  Mon Jan 13 13:29:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 13:29:45 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <HDHz6YY_yMee4MQtLcxHM-k_h7wyG2x3Y0aDtPSizjA=.f328bf5f-b5d7-444a-b7d5-e8dacdad2fcb@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

They are interchangeable and some places  used UINTX_FORMAT when they should have used SIZE_FORMAT.
Better to have just one and just use %zu, which looks better in the format specifiers. I'm going to do SIZE_FORMAT next but still negotiating how to handle review tedium.

The error message can be confusing though because the error message for %z refers to size_t.   But some of our use of intx should probably be size_t.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2587101349

From coleenp at openjdk.org  Mon Jan 13 15:49:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 15:49:15 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add Oracle copyright to shenandoah files for this change.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/ae9d9f6f..763c3908

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

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

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

From kbarrett at openjdk.org  Mon Jan 13 16:54:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 Jan 2025 16:54:53 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <DCTXOr09_AWxG0ET1DP5q5n8B6TN29PM4_Cj6DGHB6o=.b4cedcdd-90c7-4fff-a100-aa49761c5e41@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

Still good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2547230951

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 coleenp at openjdk.org  Mon Jan 13 18:52:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 18:52:56 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier
Message-ID: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>

Please review this change that replaces SSIZE_FORMAT with %zd.
Tested with tier1 on Oracle supported platforms (and here with GHA).

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

Commit messages:
 - 8347566: Replace SSIZE_FORMAT with 'z' length modifier

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

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

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 dlong at openjdk.org  Mon Jan 13 19:35:43 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 13 Jan 2025 19:35:43 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier
In-Reply-To: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
Message-ID: <hVCY58k48zW-5o8GQh2jj62FYPNOXHiGV7EcL0_Yn8M=.90ba6845-ad87-450e-9f3f-43df3fd433b5@github.com>

On Mon, 13 Jan 2025 18:47:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change that replaces SSIZE_FORMAT with %zd.
> Tested with tier1 on Oracle supported platforms (and here with GHA).

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 160:

> 158:   uintx free_bits = mutator_bits | collector_bits | old_collector_bits;
> 159:   uintx notfree_bits =  ~free_bits;
> 160:   log_debug(gc)("%6zu : " SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0,

Why is this %6zu instead of %6zd?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23084#discussion_r1913708708

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 coleenp at openjdk.org  Mon Jan 13 20:39:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 20:39:53 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
Message-ID: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>

> Please review this change that replaces SSIZE_FORMAT with %zd.
> Tested with tier1 on Oracle supported platforms (and here with GHA).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix one zu -> zd.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23084/files
  - new: https://git.openjdk.org/jdk/pull/23084/files/1cf9c88e..011ab8d2

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

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

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

From coleenp at openjdk.org  Mon Jan 13 20:39:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 20:39:53 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <hVCY58k48zW-5o8GQh2jj62FYPNOXHiGV7EcL0_Yn8M=.90ba6845-ad87-450e-9f3f-43df3fd433b5@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <hVCY58k48zW-5o8GQh2jj62FYPNOXHiGV7EcL0_Yn8M=.90ba6845-ad87-450e-9f3f-43df3fd433b5@github.com>
Message-ID: <HdJtYLqVu4VM84WRo132ZbnYFL38qWpoOn-jh2flklY=.dccec54b-1e74-4a97-abc4-2affce9a0755@github.com>

On Mon, 13 Jan 2025 19:32:06 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix one zu -> zd.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 160:
> 
>> 158:   uintx free_bits = mutator_bits | collector_bits | old_collector_bits;
>> 159:   uintx notfree_bits =  ~free_bits;
>> 160:   log_debug(gc)("%6zu : " SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0,
> 
> Why is this %6zu instead of %6zd?

I must have done this one by hand.  Thank you for spotting it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23084#discussion_r1913773820

From dlong at openjdk.org  Mon Jan 13 20:44:40 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 13 Jan 2025 20:44:40 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <GnHSd3B0aTvgBFz_ouq9tGgRY19JZG7iuM1yZeXhPiE=.26a8ae55-d052-4d74-bd33-84fd84f782b6@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23084#pullrequestreview-2547837099

From dholmes at openjdk.org  Mon Jan 13 21:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 21:07:44 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <9iKSUKvDXxUoqoAxOYVEqzUGmf2PQwDLy_MfbFABs88=.30a14b62-a21e-4a6e-bf32-31454689a33f@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2547892700

From coleenp at openjdk.org  Mon Jan 13 22:02:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 22:02:36 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <dxeMy5zlOeZkj14vDUWM3AaErUk5hkFVIy7H6hKZKRs=.d6bfc8ce-ada3-42bf-9204-02738bb45005@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Thanks Dean.

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

PR Comment: https://git.openjdk.org/jdk/pull/23084#issuecomment-2588311136

From coleenp at openjdk.org  Mon Jan 13 22:06:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 22:06:49 GMT
Subject: Integrated: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <VmPON0_Nu8ZAN4fnn9hVsqXUld7G0_30HXd3mMO2Qc0=.47ab2394-eab0-4aea-9cd4-a68efb95e5c2@github.com>

On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

This pull request has now been integrated.

Changeset: 379d05bc
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/379d05bcc130446086786ecf6ca5a6b8e977386c
Stats:     344 lines in 83 files changed: 6 ins; 19 del; 319 mod

8346990: Remove INTX_FORMAT and UINTX_FORMAT macros

Reviewed-by: kbarrett, dholmes, matsaave

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

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

From coleenp at openjdk.org  Mon Jan 13 22:06:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 22:06:48 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <etmswFtqnPXNzddiLOqeIxwK6Qk-Z0oi6ldpjTB1icQ=.bc830122-dddb-4c0c-964a-f0d2a4116535@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

Thank you Matias, Kim and David.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2588312123

From dholmes at openjdk.org  Tue Jan 14 01:18:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Jan 2025 01:18:43 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <yM_EWXlhNXi16bxEFqX_NIw0ja9wU2iI5g7ZT0gljA8=.45b47ef6-43aa-400b-a68a-84608478880a@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

We have belatedly discovered that `0x%zx` and `%#zx` behave differently in their handling of zero. The former prints `0x0` while the latter just prints `0`. This has broken the compiler replay tests as the parsing of 0 no longer works.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2588550581

From dholmes at openjdk.org  Tue Jan 14 06:55:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Jan 2025 06:55:41 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <LjnRnINSs9CmlHycT7C1L1gafsev-McP9LsWTLdQWAQ=.49851e3f-973c-49e4-8ec1-6a6345cc7cf7@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Looks good!

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23084#pullrequestreview-2548932282

From kbarrett at openjdk.org  Tue Jan 14 08:18:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Jan 2025 08:18:39 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <rpWAnYvava6WwBLM5XU1qZ78Vv3m6fUJdUvRh0CZzno=.01c18c03-eff6-40cc-b927-7adac4cc858d@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23084#pullrequestreview-2549050399

From coleenp at openjdk.org  Tue Jan 14 12:37:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 12:37:49 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <EKtaBrbhzHw0bog9_eeqqVjg5tRby9mWji9pFkZtQK8=.fee29932-3a64-4d73-ace6-330e83862210@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Thanks Dean, Kim and David for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23084#issuecomment-2589796008

From coleenp at openjdk.org  Tue Jan 14 12:37:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 12:37:50 GMT
Subject: Integrated: 8347566: Replace SSIZE_FORMAT with 'z' length modifier
In-Reply-To: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
Message-ID: <aVkPmra_apc2MpmtYouo1ytZ_dD3i7JnCdIo50LBQac=.58a86709-62a9-4d6d-a74d-2d0780c5992b@github.com>

On Mon, 13 Jan 2025 18:47:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change that replaces SSIZE_FORMAT with %zd.
> Tested with tier1 on Oracle supported platforms (and here with GHA).

This pull request has now been integrated.

Changeset: b4cd3b12
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b4cd3b12967688d78028f548db76d24cfe654614
Stats:     81 lines in 7 files changed: 2 ins; 3 del; 76 mod

8347566: Replace SSIZE_FORMAT with 'z' length modifier

Reviewed-by: dlong, dholmes, kbarrett

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

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

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 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 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 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: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 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 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 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: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: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 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 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 cslucas at openjdk.org  Fri Jan 17 05:24:12 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 17 Jan 2025 05:24:12 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables
Message-ID: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>

In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 

The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.

The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.

Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.

The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.

Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.

Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

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

Commit messages:
 - Relocation of Card Tables

Changes: https://git.openjdk.org/jdk/pull/23170/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343468
  Stats: 372 lines in 30 files changed: 200 ins; 114 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/23170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170

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

From shade at openjdk.org  Fri Jan 17 08:46:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 17 Jan 2025 08:46:49 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

I do wonder if you can avoid a lot if not all arch-specific changes, if Shenandoah barrier set: a) does not use `MacroAssembler::load_byte_map_base` directly; b) returns deliberately bad pointer from `byte_map_base()`, so that C2 matcher would never match, and accidental use of `byte_map_base()` would cleanly crash.

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

PR Review: https://git.openjdk.org/jdk/pull/23170#pullrequestreview-2558274955

From mdoerr at openjdk.org  Fri Jan 17 11:13:36 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 17 Jan 2025 11:13:36 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <KgEhmgv_Fi10MEnLFlnhom1-EgF6-6H7c0Ac2zZapJA=.a145a10b-d65c-4fae-a3f2-d538663863c2@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 600:

> 598: 
> 599:   __ ld(tmp, in_bytes(ShenandoahThreadLocalData::card_table_offset()), R16_thread);
> 600:   __ add(tmp, /* card_table_base */ tmp, R0);

This looks wrong. R0 is an uninitialized register. We shouldn't add it. (Note that it is used as scratch register in the old code.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920010189

From ysr at openjdk.org  Fri Jan 17 15:09:35 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 17 Jan 2025 15:09:35 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <lNguXjkHP0ET0RdCYmR_QIlNUQlwa_jIxklZ4pMLqYc=.952dcda2-8cdf-4bd9-bf8f-6897f9267d1a@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

Thanks for implementing this very important feature which already improves performance (and which will further unlock better performance when init-mark becomes a per-thread handshake in the future).

> Our internal performance testing showed a significant reduction in the duration of init-mark pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.

It would be great if you can include some performance numbers either in this PR or, preferably, in the JBS ticket.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2598567393

From kdnilsen at openjdk.org  Fri Jan 17 21:25:37 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 17 Jan 2025 21:25:37 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

Thanks for figuring out how to make all of this work.  It represents a very significant improvement to the GenShen implementation.

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp line 120:

> 118:   if (ShenandoahCardBarrier) {
> 119:     // Every thread always have a pointer to the _current_ _write_ version of the card table.
> 120:     // The JIT'ed code will use this address (+card entry offset) to marke card's as dirty.

typo here: "to mark cards as dirty"

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 228:

> 226: // This avoids the need to synchronize reads of the table by the GC workers doing
> 227: // remset scanning, on the one hand, with the dirtying of the table by mutators
> 228: // and by the GC workers doing remset scans, on the other.

Remove "and by the the GC workers doing remset scans" from this comment, so it reads:
"This avoids the need to synchronize reads of the table by the GC workers doing
remset scanning, on the one hand, with the dirtying of the table by mutators on the other.

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 121:

> 119:   CardValue* bp = &(read_table)[0];
> 120:   CardValue* end_bp = &(read_table)[_card_table->last_valid_index()];
> 121: 

Looks like there may be an off-by-one error here, or a bad name for "last_valid_index()".  The following loop should continue while bp <= end_bp.

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 632:

> 630:   CardValue* end_bp = &(new_ptr)[_card_table->last_valid_index()];
> 631: 
> 632:   while (start_bp < end_bp) {

Same issue here as mentioned above.  So our validation test doesn't catch our failure to overwrite last index value with clean value.

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

PR Review: https://git.openjdk.org/jdk/pull/23170#pullrequestreview-2559986861
PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920769089
PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920775685
PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920778272
PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920779535

From wkemper at openjdk.org  Fri Jan 17 23:22:44 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Jan 2025 23:22:44 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
Message-ID: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>

This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

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

Commit messages:
 - Fix whitespace
 - Do not let heap inspection/dump run GC on VM thread

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

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

From wkemper at openjdk.org  Fri Jan 17 23:37:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Jan 2025 23:37:37 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <Xo6j7jhnwGy6HmYI8cCz8ZwzrELhpkINTIxZi2dDB8E=.364b3488-d140-4183-876b-763fabe4498e@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp line 44:

> 42: #define BIND(label) bind(label); BLOCK_COMMENT(#label ":")
> 43: 
> 44: void CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,

Is it necessary to modify the `cardTableBarrierSetAssembler*` classes? I believe Shenandoah just uses the `shenandoahBarrierSetAssembler*` classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920873939

From kdnilsen at openjdk.org  Fri Jan 17 23:47:35 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 17 Jan 2025 23:47:35 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <SnfMsHvY_xs0wrr4eOBK_gEhj-Pu5ZXxzhsvnU_8F0I=.bbc037cc-dd23-4f07-b985-a52c12717aca@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

Thanks for handling this.

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

Marked as reviewed by kdnilsen (Author).

PR Review: https://git.openjdk.org/jdk/pull/23186#pullrequestreview-2560162856

From ysr at openjdk.org  Sat Jan 18 01:55:35 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 18 Jan 2025 01:55:35 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <lgntdS6_JTPWVv8wie7b9mt5QiWgv8X3_WT9fust2C4=.992dc3e8-c9e6-47b4-a251-185a5491cc01@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

LGTM ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23186#pullrequestreview-2560240341

From ysr at openjdk.org  Sat Jan 18 01:59:44 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 18 Jan 2025 01:59:44 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <_6iRDLUcANVcjyQJOF-M9G8boXICY8mSiQRkl8efsDA=.5dc4916f-0707-44b4-a384-af946bea8518@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

Please add a suitable testing section/description to the PR (perhaps inducing the conditions that might cause the original issue to manifest without the fix).

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

PR Comment: https://git.openjdk.org/jdk/pull/23186#issuecomment-2599466706

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 wkemper at openjdk.org  Tue Jan 21 18:38:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 18:38:50 GMT
Subject: Integrated: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <w52MQ3D9h1dDH78nZbCGLtxNRPvyPdqKH8sIkf33L_Q=.d4309bf1-4934-4465-a976-70f904f968fb@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.
> 
> ## Testing
> 
> Shenandoh's jtreg test: `gc/shenandoah/TestJcmdHeapDump.java` simply takes a heap dump of itself. Before this change I observed a failure rate of approximately 1/6000 executions. The assertion is violated when the VM thread attempts to run a collection which is not coordinated by Shenandoah's control thread. This specific assertion happens because the default implementation of `collect_as_vm_thread` modifies the `_gc_cause` field in ways that Shenandoah does not expect. Without this assertion, one can only imagine the chaos that would ensue.

This pull request has now been integrated.

Changeset: 6a29a811
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a29a8110ec38b4adc8163ba8651cbc935353f1d
Stats:     23 lines in 4 files changed: 15 ins; 1 del; 7 mod

8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause

Reviewed-by: kdnilsen, ysr

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

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

From wkemper at openjdk.org  Tue Jan 21 18:52:48 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 18:52:48 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
Message-ID: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>

This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

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

Commit messages:
 - Backport 6a29a8110ec38b4adc8163ba8651cbc935353f1d

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

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

From wkemper at openjdk.org  Tue Jan 21 18:54:12 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 18:54:12 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
Message-ID: <ajCySaX-pkkYozSNClK3zLdwXNrfY6Ywg76P6B6_IUU=.623dd608-db6c-48ee-9f4a-b32a72f5be10@github.com>

This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

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

Commit messages:
 - Backport 6a29a8110ec38b4adc8163ba8651cbc935353f1d

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/151/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345750
  Stats: 23 lines in 4 files changed: 15 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/151.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/151/head:pull/151

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/151

From wkemper at openjdk.org  Tue Jan 21 21:30:58 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 21:30:58 GMT
Subject: Integrated: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <ajCySaX-pkkYozSNClK3zLdwXNrfY6Ywg76P6B6_IUU=.623dd608-db6c-48ee-9f4a-b32a72f5be10@github.com>
References: <ajCySaX-pkkYozSNClK3zLdwXNrfY6Ywg76P6B6_IUU=.623dd608-db6c-48ee-9f4a-b32a72f5be10@github.com>
Message-ID: <qjRAN2bQ8aknEwW8gt8C_crLufzmYfynRAwLwepw33o=.ffb0527b-f2c0-4c54-a473-fb8805a13deb@github.com>

On Tue, 21 Jan 2025 18:48:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

This pull request has now been integrated.

Changeset: 31e89a54
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/31e89a54c25465d89353873b8ec092e93066341b
Stats:     23 lines in 4 files changed: 15 ins; 1 del; 7 mod

8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause

Backport-of: 6a29a8110ec38b4adc8163ba8651cbc935353f1d

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/151

From ysr at openjdk.org  Tue Jan 21 22:45:37 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 21 Jan 2025 22:45:37 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <G4TSKokMyIFKnDnZlYitEgSNHtuRhoZfynStRztcDIk=.dbe42d6a-0b0d-4ae3-b267-9ca3c8d1a53b@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23221#pullrequestreview-2565838091

From wkemper at openjdk.org  Tue Jan 21 23:12:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 23:12:40 GMT
Subject: [jdk24] Integrated: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <TGmKVQYKJrZ4FVBdpfAWh0MXoKYvucAKm3jYRSqZUXs=.4d77266b-d2a3-4254-94b0-5e3cfdee9439@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

This pull request has now been integrated.

Changeset: febcfd69
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/febcfd69ffe88e8a9d3cdf267bc062816577f868
Stats:     23 lines in 4 files changed: 15 ins; 1 del; 7 mod

8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause

Reviewed-by: ysr
Backport-of: 6a29a8110ec38b4adc8163ba8651cbc935353f1d

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

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

From ysr at openjdk.org  Tue Jan 21 23:28:35 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 21 Jan 2025 23:28:35 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
Message-ID: <tI-a6z8mlKxmghtBp4SW71IC_DZbd9P6QvhEzUNZTuY=.80947a0d-95e9-4463-8e27-3dc21d87a370@github.com>

On Fri, 17 Jan 2025 21:16:00 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 228:
> 
>> 226: // This avoids the need to synchronize reads of the table by the GC workers doing
>> 227: // remset scanning, on the one hand, with the dirtying of the table by mutators
>> 228: // and by the GC workers doing remset scans, on the other.
> 
> Remove "and by the the GC workers doing remset scans" from this comment, so it reads:
> "This avoids the need to synchronize reads of the table by the GC workers doing
> remset scanning, on the one hand, with the dirtying of the table by mutators on the other.

@kdnilsen , when are the existing intergenerational pointers (represented by (a subset of) the dirty cards in the read table) transferred to the write table?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1924486803

From cslucas at openjdk.org  Wed Jan 22 01:53:38 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 22 Jan 2025 01:53:38 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
Message-ID: <aQPrGOirvNOjdAwZsSGMxaiwnicOdaH1xNkjYsjhdgU=.354f17d5-df27-4165-a896-34583a6550d7@github.com>

On Fri, 17 Jan 2025 21:19:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 121:
> 
>> 119:   CardValue* bp = &(read_table)[0];
>> 120:   CardValue* end_bp = &(read_table)[_card_table->last_valid_index()];
>> 121: 
> 
> Looks like there may be an off-by-one error here, or a bad name for "last_valid_index()".  The following loop should continue while bp <= end_bp.

Good catch, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1924583163

From cslucas at openjdk.org  Wed Jan 22 01:53:37 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 22 Jan 2025 01:53:37 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <Xo6j7jhnwGy6HmYI8cCz8ZwzrELhpkINTIxZi2dDB8E=.364b3488-d140-4183-876b-763fabe4498e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <Xo6j7jhnwGy6HmYI8cCz8ZwzrELhpkINTIxZi2dDB8E=.364b3488-d140-4183-876b-763fabe4498e@github.com>
Message-ID: <jjpV9jJCY6UUY_hf-UFwDu3hh6Ug8qg_kSKvganUFMQ=.377c98a6-a202-4509-9142-2f98977bf006@github.com>

On Fri, 17 Jan 2025 23:35:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp line 44:
> 
>> 42: #define BIND(label) bind(label); BLOCK_COMMENT(#label ":")
>> 43: 
>> 44: void CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,
> 
> Is it necessary to modify the `cardTableBarrierSetAssembler*` classes? I believe Shenandoah just uses the `shenandoahBarrierSetAssembler*` classes.

Of course you're right! I'm reverting this change. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1924583691

From cslucas at openjdk.org  Wed Jan 22 04:23:37 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 22 Jan 2025 04:23:37 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>
Message-ID: <soLuE9bJ60nFyb_OSeyq-OBqq3uJLnTtKAHfUawfMY0=.778259ab-684a-4571-b1ef-91f9b3a1b643@github.com>

On Fri, 17 Jan 2025 08:44:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I do wonder if you can avoid a lot if not all arch-specific changes, if Shenandoah barrier set: a) does not use `MacroAssembler::load_byte_map_base` directly; b) returns deliberately bad pointer from `byte_map_base()`, so that C2 matcher would never match, and accidental use of `byte_map_base()` would cleanly crash.

@shipilev - are you suggesting to patch all `shenandoahBarrierSetAssembler_*` backend specific files to not use `load_byte_map`? It looks like we would end up in a similar situation if I go with the approach that you're suggesting - if I'm understanding it correctly.

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2606259667

From shade at openjdk.org  Wed Jan 22 17:02:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Jan 2025 17:02:50 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <soLuE9bJ60nFyb_OSeyq-OBqq3uJLnTtKAHfUawfMY0=.778259ab-684a-4571-b1ef-91f9b3a1b643@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>
 <soLuE9bJ60nFyb_OSeyq-OBqq3uJLnTtKAHfUawfMY0=.778259ab-684a-4571-b1ef-91f9b3a1b643@github.com>
Message-ID: <Q_Vj8HgbyXfh-N4-PCFksQb1iW3c6TAquTtz2odKRDw=.3a0652a2-bd39-4aeb-b4cd-640592902734@github.com>

On Wed, 22 Jan 2025 04:20:57 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> > I do wonder if you can avoid a lot if not all arch-specific changes, if Shenandoah barrier set: a) does not use `MacroAssembler::load_byte_map_base` directly; b) returns deliberately bad pointer from `byte_map_base()`, so that C2 matcher would never match, and accidental use of `byte_map_base()` would cleanly crash.
> 
> @shipilev - are you suggesting to patch all `shenandoahBarrierSetAssembler_*` backend specific files to not use `load_byte_map`? It looks like we would end up in a similar situation if I go with the approach that you're suggesting - if I'm understanding it correctly.

Yes, I was thinking that if Shenandoah cannot use super-class `load_byte_map` and needs its own implementation, then it makes sense that Shenandoah barrier set should be using a special implementation directly instead of hacking the super-class implementation? 

But mostly I want to avoid unnecessary changes in files that are not related to Shenandoah :)

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2607782057

From dholmes at openjdk.org  Wed Jan 22 21:02:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 21:02:00 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <vQSFQilU7ukjazHSDGhoFFkxv5FlTQ2hsuh_cF28zK0=.cff0d302-b74d-40c0-9716-251f62541488@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

@earthling-amzn and @ysramakrishna  JDK 24 is already in RDP2 and as such this P3 issue should not have been integrated there. Did you really intend to send this to jdk24u?

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

PR Comment: https://git.openjdk.org/jdk/pull/23221#issuecomment-2608255604

From cslucas at openjdk.org  Thu Jan 23 04:58:46 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 23 Jan 2025 04:58:46 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v2]
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <VwqgWCSVMnDqsnmjkjwyv5dvkle51XH3PTJSJqeN-TE=.51e7e425-87d2-4540-8cfa-1697571cfb75@github.com>

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Addressing PR comments: some refactorings, ppc fix, off-by-one fix.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23170/files
  - new: https://git.openjdk.org/jdk/pull/23170/files/87a9993a..124c5f70

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

  Stats: 82 lines in 9 files changed: 25 ins; 45 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170

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

From cslucas at openjdk.org  Thu Jan 23 05:45:43 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 23 Jan 2025 05:45:43 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

Cesar Soares Lucas 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 master
 - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
 - Relocation of Card Tables

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

Changes: https://git.openjdk.org/jdk/pull/23170/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=02
  Stats: 318 lines in 30 files changed: 161 ins; 95 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/23170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170

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

From cslucas at openjdk.org  Thu Jan 23 05:45:43 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 23 Jan 2025 05:45:43 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <Q_Vj8HgbyXfh-N4-PCFksQb1iW3c6TAquTtz2odKRDw=.3a0652a2-bd39-4aeb-b4cd-640592902734@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>
 <soLuE9bJ60nFyb_OSeyq-OBqq3uJLnTtKAHfUawfMY0=.778259ab-684a-4571-b1ef-91f9b3a1b643@github.com>
 <Q_Vj8HgbyXfh-N4-PCFksQb1iW3c6TAquTtz2odKRDw=.3a0652a2-bd39-4aeb-b4cd-640592902734@github.com>
Message-ID: <txKeuhHhBdvZiQtPVXMGE0WzUfqrXEnljxYxc1f4ypY=.04c0e006-da59-47b0-a9e7-18b55fa9e338@github.com>

On Wed, 22 Jan 2025 17:00:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > I do wonder if you can avoid a lot if not all arch-specific changes, if Shenandoah barrier set: a) does not use `MacroAssembler::load_byte_map_base` directly; b) returns deliberately bad pointer from `byte_map_base()`, so that C2 matcher would never match, and accidental use of `byte_map_base()` would cleanly crash.
> > 
> > 
> > @shipilev - are you suggesting to patch all `shenandoahBarrierSetAssembler_*` backend specific files to not use `load_byte_map`? It looks like we would end up in a similar situation if I go with the approach that you're suggesting - if I'm understanding it correctly.
> 
> Yes, I was thinking that if Shenandoah cannot use super-class `load_byte_map` and needs its own implementation, then it makes sense that Shenandoah barrier set should be using a special implementation directly instead of hacking the super-class implementation?
> 
> But mostly I want to avoid unnecessary changes in files that are not related to Shenandoah :)

@shipilev - Please, take a look at the latest changes when you can.

> It would be great if you can include some performance numbers either in this PR or, preferably, in the JBS ticket.

@ysramakrishna - I'm working on that!

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2608907272

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 wkemper at openjdk.org  Thu Jan 23 14:24:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 23 Jan 2025 14:24:41 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <cBGoToEI9qAHIojGX4Mpz-OFVmFpIy52e4ofGYk5Y7o=.55922be5-c189-477a-885c-a40223d6d183@github.com>

Merges tag jdk-21.0.6-ga

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

Commit messages:
 - 8347010: [21u] Remove designator DEFAULT_PROMOTED_VERSION_PRE=ea for release 21.0.6
 - 8339180: Enhanced Building of Processes: Follow-on Issue
 - 8336564: Enhance mask blit functionality redux
 - 8335428: Enhanced Building of Processes
 - 8330045: Enhance array handling

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/152/files
  Stats: 91 lines in 4 files changed: 56 ins; 8 del; 27 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/152.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/152/head:pull/152

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/152

From mdoerr at openjdk.org  Thu Jan 23 15:58:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 15:58:51 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
Message-ID: <_DLDS4E1k7FLGIsHsm1_tjnX_D5xWQTA3CBUu_3nXRE=.5462cd0d-4fbb-4e1b-860f-495f14b54fb1@github.com>

On Thu, 23 Jan 2025 05:45:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Cesar Soares Lucas 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 master
>  - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
>  - Relocation of Card Tables

The ppc fix looks good. Thanks! I guess we should rerun tests shortly before integration. There are currently many Shenandoah issues (mostly related to GenShen).

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2610196760

From kcr at openjdk.org  Thu Jan 23 16:27:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Jan 2025 16:27:52 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <bJY35XOxd5GMfhJKn7wLEMxFTSMQ17CHm3ZI0cfMegU=.3dd38c81-4908-4c5c-956c-29dd1cdc1322@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

@earthling-amzn Did you see David's question? I think this should not have been integrated to jdk24 given the RDP2 rules. Was this instead intended for jdk24u (for 24.0.1)?

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

PR Comment: https://git.openjdk.org/jdk/pull/23221#issuecomment-2610302874

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 cslucas at openjdk.org  Thu Jan 23 21:29:47 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 23 Jan 2025 21:29:47 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <_DLDS4E1k7FLGIsHsm1_tjnX_D5xWQTA3CBUu_3nXRE=.5462cd0d-4fbb-4e1b-860f-495f14b54fb1@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
 <_DLDS4E1k7FLGIsHsm1_tjnX_D5xWQTA3CBUu_3nXRE=.5462cd0d-4fbb-4e1b-860f-495f14b54fb1@github.com>
Message-ID: <qDoub4RmoYmn6KNd2KwmM2HIH-FZlDfz8g1MitgcHwQ=.8ded4b8b-73e1-4199-862b-4da4b0b83341@github.com>

On Thu, 23 Jan 2025 15:56:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> There are currently many Shenandoah issues (mostly related to GenShen).

@TheRealMDoerr - are the issues coming from a build with this patch or something prior?

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2611052027

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 mdoerr at openjdk.org  Thu Jan 23 23:16:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 23:16:47 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <qDoub4RmoYmn6KNd2KwmM2HIH-FZlDfz8g1MitgcHwQ=.8ded4b8b-73e1-4199-862b-4da4b0b83341@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
 <_DLDS4E1k7FLGIsHsm1_tjnX_D5xWQTA3CBUu_3nXRE=.5462cd0d-4fbb-4e1b-860f-495f14b54fb1@github.com>
 <qDoub4RmoYmn6KNd2KwmM2HIH-FZlDfz8g1MitgcHwQ=.8ded4b8b-73e1-4199-862b-4da4b0b83341@github.com>
Message-ID: <cJAazPehWZ1CHqkSKWSqkHrMcC9x44Aq6r0GKj0u6Nk=.9ce49f16-00a8-4ba2-9200-3dd7ea44b01e@github.com>

On Thu, 23 Jan 2025 21:27:36 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> > There are currently many Shenandoah issues (mostly related to GenShen).
> 
> @TheRealMDoerr - are the issues coming from a build with this patch or something prior?

Before this patch. We have linked the issues we found with [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511).

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2611204842

From fyang at openjdk.org  Fri Jan 24 01:03:51 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 24 Jan 2025 01:03:51 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
Message-ID: <MDGRV75H1vIpGZRwc-NFoOOq5a5SKnl3G-q0pIy9CLo=.82603af9-094c-4048-8319-23690b30260e@github.com>

On Thu, 23 Jan 2025 05:45:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Cesar Soares Lucas 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 master
>  - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
>  - Relocation of Card Tables

FYI: `gtest:all` and `hotspot_gc_shenandoah` are clean on linux-riscv64 platform with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2611324901

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 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 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 mdoerr at openjdk.org  Fri Jan 24 09:49:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Jan 2025 09:49:50 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
Message-ID: <oIoDgp2uO0H7OWF5EOgiL9UNSBgPv6xmk0Y9mK5uGj8=.20871b16-5adc-42cb-83e0-b62d9df51485@github.com>

On Thu, 23 Jan 2025 05:45:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Cesar Soares Lucas 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 master
>  - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
>  - Relocation of Card Tables

I have run this PR through our nightly tests on all our platforms and there were no new issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2612094642

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 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 18:53:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jan 2025 18:53:56 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <cBGoToEI9qAHIojGX4Mpz-OFVmFpIy52e4ofGYk5Y7o=.55922be5-c189-477a-885c-a40223d6d183@github.com>
References: <cBGoToEI9qAHIojGX4Mpz-OFVmFpIy52e4ofGYk5Y7o=.55922be5-c189-477a-885c-a40223d6d183@github.com>
Message-ID: <tvSOB_HT-wSKJI6MLLTRKi4Mr6zV_ZyxuHm1Ll6Ci9k=.fdd8d78d-4e05-45b5-9b58-5287f5d5cc3b@github.com>

On Thu, 23 Jan 2025 14:19:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.6-ga

This pull request has now been integrated.

Changeset: 89e520b5
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/89e520b598077bcf9db584b63e6e4aad1f505c5b
Stats:     91 lines in 4 files changed: 56 ins; 8 del; 27 mod

Merge

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/152

From wkemper at openjdk.org  Fri Jan 24 18:53:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jan 2025 18:53:55 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <cBGoToEI9qAHIojGX4Mpz-OFVmFpIy52e4ofGYk5Y7o=.55922be5-c189-477a-885c-a40223d6d183@github.com>
References: <cBGoToEI9qAHIojGX4Mpz-OFVmFpIy52e4ofGYk5Y7o=.55922be5-c189-477a-885c-a40223d6d183@github.com>
Message-ID: <Fqk6KYxcZHu4_o-YaZJPhicsoBUPyCAzbDmL6QyQFKo=.78504219-3410-4e6c-bfe5-405866e4cac8@github.com>

> Merges tag jdk-21.0.6-ga

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.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/152/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/152/files/7069f193..7069f193

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=152&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=152&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/152.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/152/head:pull/152

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/152

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 cslucas at openjdk.org  Sat Jan 25 02:38:55 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Sat, 25 Jan 2025 02:38:55 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <lNguXjkHP0ET0RdCYmR_QIlNUQlwa_jIxklZ4pMLqYc=.952dcda2-8cdf-4bd9-bf8f-6897f9267d1a@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <lNguXjkHP0ET0RdCYmR_QIlNUQlwa_jIxklZ4pMLqYc=.952dcda2-8cdf-4bd9-bf8f-6897f9267d1a@github.com>
Message-ID: <yisMPBJ3kO9OIF1KvKxN8btxfaL9THkrFvKC8YRsdYs=.fff2a972-2a79-4628-894c-4e96e4339fa5@github.com>

On Fri, 17 Jan 2025 15:06:33 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Thanks for implementing this very important feature which already improves performance (and which will further unlock better performance when init-mark becomes a per-thread handshake in the future).
> 
>> Our internal performance testing showed a significant reduction in the duration of init-mark pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> It would be great if you can include some performance numbers either in this PR or, preferably, in the JBS ticket.
> 
> Thanks!

@ysramakrishna - I attached to the RFE a graph showing the reduction in init-pause duration when executing SPECJBB2015 on x86_64.

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2613735937

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 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 kdnilsen at openjdk.org  Mon Jan 27 19:28:47 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 27 Jan 2025 19:28:47 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <tI-a6z8mlKxmghtBp4SW71IC_DZbd9P6QvhEzUNZTuY=.80947a0d-95e9-4463-8e27-3dc21d87a370@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
 <tI-a6z8mlKxmghtBp4SW71IC_DZbd9P6QvhEzUNZTuY=.80947a0d-95e9-4463-8e27-3dc21d87a370@github.com>
Message-ID: <0CQeRpNMFlkcHzWqgjuu5-39K6Abq0q_yQQbvsZiZng=.710d6f80-99f8-419c-ae41-cfa3c6b2047c@github.com>

On Tue, 21 Jan 2025 23:25:27 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 228:
>> 
>>> 226: // This avoids the need to synchronize reads of the table by the GC workers doing
>>> 227: // remset scanning, on the one hand, with the dirtying of the table by mutators
>>> 228: // and by the GC workers doing remset scans, on the other.
>> 
>> Remove "and by the the GC workers doing remset scans" from this comment, so it reads:
>> "This avoids the need to synchronize reads of the table by the GC workers doing
>> remset scanning, on the one hand, with the dirtying of the table by mutators on the other.
>
> @kdnilsen , when are the existing intergenerational pointers (represented by (a subset of) the dirty cards in the read table) transferred to the write table?

That happens during remembered set scanning.  If the remembered set scan (from the read table) finds that certain cards still hold interesting pointers, the card will be dirtied in the write table.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1931077697

From ssarathi at openjdk.org  Tue Jan 28 08:37:35 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Tue, 28 Jan 2025 08:37:35 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters
Message-ID: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>

PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.

JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

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

Commit messages:
 - Renaming the Condition Registers

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

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

From amitkumar at openjdk.org  Tue Jan 28 09:09:56 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 28 Jan 2025 09:09:56 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters
In-Reply-To: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
Message-ID: <Mh-k74Jeq1wh38ZZ1GN3VZkjX4pUDm1kXbZ-we1WJV8=.e352ca27-b44d-4968-bb96-42b97b35caeb@github.com>

On Tue, 28 Jan 2025 08:31:59 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
> 
> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

Please update copyright header years as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/23325#issuecomment-2618365794

From aph at openjdk.org  Tue Jan 28 09:21:50 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 28 Jan 2025 09:21:50 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters
In-Reply-To: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
Message-ID: <EkXatJZJLBKMKedIQG_BtgWU8j4za31nDoO6oRHkLl8=.48769d0a-2730-46b3-b1fd-68c72c1ebc82@github.com>

On Tue, 28 Jan 2025 08:31:59 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
> 
> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

I understand the motivation, but maybe the reason this was never done before is that it will make back-porting fixes harder. They will never apply cleanly to old versions, and will all have to be adjusted manually.

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

PR Comment: https://git.openjdk.org/jdk/pull/23325#issuecomment-2618394421

From ssarathi at openjdk.org  Tue Jan 28 11:58:00 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Tue, 28 Jan 2025 11:58:00 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters [v2]
In-Reply-To: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
Message-ID: <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>

> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
> 
> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

Sorna Sarathi N has updated the pull request incrementally with one additional commit since the last revision:

  Updated the copyright header years for the edited files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23325/files
  - new: https://git.openjdk.org/jdk/pull/23325/files/74ca1f53..a0b07116

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

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

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

From cslucas at openjdk.org  Tue Jan 28 18:37:48 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 28 Jan 2025 18:37:48 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
Message-ID: <k1JWoseWNdq4KOByURGUWCbLdTW2m_-i_L6_Op8NZv4=.4ee6440d-4d6e-440b-bc1f-218b25093abb@github.com>

On Thu, 23 Jan 2025 05:45:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Cesar Soares Lucas 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 master
>  - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
>  - Relocation of Card Tables

Anyone has any other concern / comment ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2619780113

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 ssubramaniam at openjdk.org  Thu Jan 30 00:12:46 2025
From: ssubramaniam at openjdk.org (Satyen Subramaniam)
Date: Thu, 30 Jan 2025 00:12:46 GMT
Subject: RFR: 8348610: GenShen: TestShenandoahEvacuationInformationEvent failed
 with setRegions >= regionsFreed: expected 1 >= 57
Message-ID: <xREh-BpJoPVPebBRIs8aEsAm8qmI1mcqJjaN8dw2u2Y=.bcf359a2-3148-4d4a-a7a1-0842448efe44@github.com>

Renaming `ShenandoahEvacuationInformation.freedRegions` to `ShenandoahEvacuationInformation.freeRegions` for clarity, and fixing incorrect assertion in  TestShenandoahEvacuationInformationEvent.cpp

Tested with tier 1, tier 2, and tier 3 tests.

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

Commit messages:
 - Adjusting ShenandoahEvacuationInformation event and test assertions

Changes: https://git.openjdk.org/shenandoah/pull/558/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=558&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348610
  Stats: 14 lines in 5 files changed: 2 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/shenandoah/pull/558.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/558/head:pull/558

PR: https://git.openjdk.org/shenandoah/pull/558

From ssubramaniam at openjdk.org  Thu Jan 30 04:49:22 2025
From: ssubramaniam at openjdk.org (Satyen Subramaniam)
Date: Thu, 30 Jan 2025 04:49:22 GMT
Subject: RFR: 8348610: GenShen: TestShenandoahEvacuationInformationEvent failed
 with setRegions >= regionsFreed: expected 1 >= 57
Message-ID: <M-8yf6fmPVUPLubCfG83quv9jTAHkqhcrgy_dHy288M=.70835c1f-be6c-4ff7-b2a1-1eb2b96ba69f@github.com>

Renaming `ShenandoahEvacuationInformation.freedRegions` to `ShenandoahEvacuationInformation.freeRegions` for clarity, and fixing incorrect assertion in  TestShenandoahEvacuationInformationEvent.cpp

Tested with tier 1, tier 2, and tier 3 tests.

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

Commit messages:
 - Adjusting ShenandoahEvacuationInformation event and test assertions

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

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

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 mdoerr at openjdk.org  Thu Jan 30 13:59:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 Jan 2025 13:59:51 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters [v2]
In-Reply-To: <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
 <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>
Message-ID: <u22ZEqlFawsy-vDmtIpkemPPjk5-tBEs0KQM2m9aqxY=.69304507-4703-4cbd-93b2-b191894f37ab@github.com>

On Tue, 28 Jan 2025 11:58:00 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

>> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
>> 
>> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)
>
> Sorna Sarathi N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the copyright header years for the edited files

Thanks for cleaning this up! LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23325#pullrequestreview-2583984594

From mdoerr at openjdk.org  Thu Jan 30 14:03:58 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 Jan 2025 14:03:58 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters
In-Reply-To: <EkXatJZJLBKMKedIQG_BtgWU8j4za31nDoO6oRHkLl8=.48769d0a-2730-46b3-b1fd-68c72c1ebc82@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
 <EkXatJZJLBKMKedIQG_BtgWU8j4za31nDoO6oRHkLl8=.48769d0a-2730-46b3-b1fd-68c72c1ebc82@github.com>
Message-ID: <sh_CidCyHycW2LF0Hn8XZhxnACJI4YGpGQMNYMxDp58=.66e2fec3-1ae4-401e-a81d-99ed6e94bd57@github.com>

On Tue, 28 Jan 2025 09:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I understand the motivation, but maybe the reason this was never done before is that it will make back-porting fixes harder. They will never apply cleanly to old versions, and will all have to be adjusted manually.

Right. The number of assembler code backports seems to be not that high. I think JDK25 is a good release to clean this up.

Please note that the PR needs a git merge.

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

PR Comment: https://git.openjdk.org/jdk/pull/23325#issuecomment-2624598272

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 rrich at openjdk.org  Thu Jan 30 15:10:53 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 30 Jan 2025 15:10:53 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters [v2]
In-Reply-To: <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
 <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>
Message-ID: <GnwpvZbY36xYDAHgMhbhmrTpxjeiDuP0GDX1S6fqt_k=.4d5d9089-a209-41f7-8ede-917da0d410fc@github.com>

On Tue, 28 Jan 2025 11:58:00 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

>> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
>> 
>> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)
>
> Sorna Sarathi N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the copyright header years for the edited files

Looks good!
Thanks, Richard.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23325#pullrequestreview-2584180313

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 wkemper at openjdk.org  Thu Jan 30 16:53:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Jan 2025 16:53:47 GMT
Subject: RFR: 8348610: GenShen: TestShenandoahEvacuationInformationEvent
 failed with setRegions >= regionsFreed: expected 1 >= 57
In-Reply-To: <M-8yf6fmPVUPLubCfG83quv9jTAHkqhcrgy_dHy288M=.70835c1f-be6c-4ff7-b2a1-1eb2b96ba69f@github.com>
References: <M-8yf6fmPVUPLubCfG83quv9jTAHkqhcrgy_dHy288M=.70835c1f-be6c-4ff7-b2a1-1eb2b96ba69f@github.com>
Message-ID: <P_PEuiuQ7mz_gQ5XYawYVr2NO-sG2EoLVyzcmrBKW4M=.55aab6c5-48d5-4171-a6e2-05d3c2dd474b@github.com>

On Thu, 30 Jan 2025 04:43:59 GMT, Satyen Subramaniam <ssubramaniam at openjdk.org> wrote:

> Renaming `ShenandoahEvacuationInformation.freedRegions` to `ShenandoahEvacuationInformation.freeRegions` for clarity, and fixing incorrect assertion in  TestShenandoahEvacuationInformationEvent.cpp
> 
> Tested with tier 1, tier 2, and tier 3 tests.

LGTM. Thank you!

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23362#pullrequestreview-2584475570

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 rrich at openjdk.org  Fri Jan 31 09:12:47 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 31 Jan 2025 09:12:47 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters [v3]
In-Reply-To: <s5bBTa-RbK7FIaP0V4kJipsQ_uFnKJsNkWoWl_7BBXA=.399ea57f-69ab-4bc3-8557-f4b260ea8276@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
 <s5bBTa-RbK7FIaP0V4kJipsQ_uFnKJsNkWoWl_7BBXA=.399ea57f-69ab-4bc3-8557-f4b260ea8276@github.com>
Message-ID: <Rpp8h-Fxr-GqJz2avPDfCdXOeEJwxxhUEZETNb0gaWQ=.cc85a53d-c0be-45b9-9d55-d1cc56edc4ca@github.com>

On Fri, 31 Jan 2025 07:01:46 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

>> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
>> 
>> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)
>
> Sorna Sarathi N 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 master
>  - Updated the copyright header years for the edited files
>  - Renaming the Condition Registers

Still good.
Thanks, Richard.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23325#pullrequestreview-2586058488

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 ssarathi at openjdk.org  Fri Jan 31 14:08:52 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Fri, 31 Jan 2025 14:08:52 GMT
Subject: Integrated: 8344983: [PPC64] Rename ConditionRegisters
In-Reply-To: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
Message-ID: <HiFWlNd2dLnqGAFfgA-54tr2v2bgKAfx2MOEqpNKWdo=.06ab16c3-16b0-438f-aa9a-d7bc7cfded46@github.com>

On Tue, 28 Jan 2025 08:31:59 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
> 
> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

This pull request has now been integrated.

Changeset: a414a591
Author:    Sorna Sarathi N <ssarathi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a414a591dd8d66f1500cd69dd65baa6ba4224c2a
Stats:     1415 lines in 32 files changed: 0 ins; 0 del; 1415 mod

8344983: [PPC64] Rename ConditionRegisters

Reviewed-by: rrich, mdoerr

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

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