From aboldtch at openjdk.org  Mon Dec  1 06:56:40 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 1 Dec 2025 06:56:40 GMT
Subject: RFR: 8351137: ZGC: Improve ZValueStorage alignment support [v7]
In-Reply-To: <GNS93cR60yXhAg3e7xq700RXmu-pYa6muIwmfJIBrac=.f1991bdf-d6fc-4255-8f04-c5717455baa6@github.com>
References: <GNS93cR60yXhAg3e7xq700RXmu-pYa6muIwmfJIBrac=.f1991bdf-d6fc-4255-8f04-c5717455baa6@github.com>
Message-ID: <J4hQcIKG2Q6TxfI3WgOcnVIVPVajJcD8pjbvhDPh45A=.a0a0a504-7b28-4786-9775-1212798ff91c@github.com>

> ZValueStorage only align the allocations to the alignment defined by the storage but ignores the alignment of the types. Right now all usages of our different storages all have types which have an alignment less than or equal to the alignment set by its storage.
> 
> I wish to improve this so that types with greater alignment than the storage alignment can be used.
> 
> The UB caused by using a type larger than the storage alignment is something I have seen materialise as returning bad address (and crashing) on Windows.
> 
> As we use `utilities/align.hpp` for our alignment utilities we only support power of two alignment, I added extra asserts here because we use the fact that `lcm(x, y) = max(x, y)` if both are powers of two. 
> 
> Testing:
>   * tier 1 through tier 5 Oracle supported platforms
>   * GHA

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

 - Merge tag 'jdk-26+26' into JDK-8351137
   
   Added tag jdk-26+26 for changeset 847fbab7
 - Merge tag 'jdk-26+21' into JDK-8351137
   
   Added tag jdk-26+21 for changeset 3e20a939
 - Merge tag 'jdk-26+19' into JDK-8351137
   
   Added tag jdk-26+19 for changeset b37a1a33
 - Merge tag 'jdk-26+18' into JDK-8351137
   
   Added tag jdk-26+18 for changeset 5251405c
 - Merge tag 'jdk-26+17' into JDK-8351137
   
   Added tag jdk-26+17 for changeset 2aafda19
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8351137
 - 8351137: ZGC: Improve ZValueStorage alignment support

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23887/files
  - new: https://git.openjdk.org/jdk/pull/23887/files/f09e28dc..fb298944

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

  Stats: 317381 lines in 2858 files changed: 205528 ins; 69542 del; 42311 mod
  Patch: https://git.openjdk.org/jdk/pull/23887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23887/head:pull/23887

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

From sjohanss at openjdk.org  Mon Dec  1 07:14:53 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 1 Dec 2025 07:14:53 GMT
Subject: RFR: 8372684: G1: Missing load_acquire() in G1 allocation path
In-Reply-To: <gx5xrN9U9omEgLsGIX_YzIJeftJbpyCUi11g1pQ67do=.ead2d396-096d-46a5-b74c-2e602d3e7f91@github.com>
References: <gx5xrN9U9omEgLsGIX_YzIJeftJbpyCUi11g1pQ67do=.ead2d396-096d-46a5-b74c-2e602d3e7f91@github.com>
Message-ID: <ITtD6WisZu2xJnhKOaoH7_gT-MMQ4lNvZLjGlzSuS6c=.83c6ee8c-ba77-49a4-85fc-af5023ffb679@github.com>

On Thu, 27 Nov 2025 18:48:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that changes some volatile atomics to the new `Atomic` construct, fixing some issue with missing load_acquire when allocating in `G1HeapRegion::par_allocate()`.
> 
> That `load_acquire` seems necessary as when setting a new allocation region, there needs to be synchronization about the contents (top/end) of the heap region. Otherwise the allocating thread might get old/previous top values sent from the corresponding storestore (I changed to a `release_store()` in `G1AllocRegion::update_alloc_region()`.
> 
> Similar issue exists in the handling of the retained regions.
> 
> I also made the `G1AllocatorRegion::_dummy_region` Atomic; synchronization is necessary for a single `release_store` at initialization. No further synchronization is necessary (just using relaxed loads) as its contents are never changed afterwards.
> 
> Performance testing, both manually on targeted benchmarks and a few general ones without differences.
> 
> Testing: gha, tier1-3
> 
> Thanks,
>   Thomas

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28543#pullrequestreview-3523464101

From tschatzl at openjdk.org  Mon Dec  1 08:09:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 1 Dec 2025 08:09:03 GMT
Subject: RFR: 8372684: G1: Missing load_acquire() in G1 allocation path
In-Reply-To: <qkXePqrreFqD5dR9ayJnKl-2fiK67VHslxgv2GQ7O7E=.c95c403e-9d59-466a-8246-f188b467ac1a@github.com>
References: <gx5xrN9U9omEgLsGIX_YzIJeftJbpyCUi11g1pQ67do=.ead2d396-096d-46a5-b74c-2e602d3e7f91@github.com>
 <qkXePqrreFqD5dR9ayJnKl-2fiK67VHslxgv2GQ7O7E=.c95c403e-9d59-466a-8246-f188b467ac1a@github.com>
Message-ID: <dL4CBYWCaAEeuq4BJUK2OTRexg9m3yrqj0I4j8-k93c=.5278703b-5437-4c55-afad-4881773cfb4f@github.com>

On Fri, 28 Nov 2025 09:13:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that changes some volatile atomics to the new `Atomic` construct, fixing some issue with missing load_acquire when allocating in `G1HeapRegion::par_allocate()`.
>> 
>> That `load_acquire` seems necessary as when setting a new allocation region, there needs to be synchronization about the contents (top/end) of the heap region. Otherwise the allocating thread might get old/previous top values sent from the corresponding storestore (I changed to a `release_store()` in `G1AllocRegion::update_alloc_region()`.
>> 
>> Similar issue exists in the handling of the retained regions.
>> 
>> I also made the `G1AllocatorRegion::_dummy_region` Atomic; synchronization is necessary for a single `release_store` at initialization. No further synchronization is necessary (just using relaxed loads) as its contents are never changed afterwards.
>> 
>> Performance testing, both manually on targeted benchmarks and a few general ones without differences.
>> 
>> Testing: gha, tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Looks good.

Thanks @kimbarrett @kstefanj for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/28543#issuecomment-3595152537

From tschatzl at openjdk.org  Mon Dec  1 08:09:05 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 1 Dec 2025 08:09:05 GMT
Subject: Integrated: 8372684: G1: Missing load_acquire() in G1 allocation path
In-Reply-To: <gx5xrN9U9omEgLsGIX_YzIJeftJbpyCUi11g1pQ67do=.ead2d396-096d-46a5-b74c-2e602d3e7f91@github.com>
References: <gx5xrN9U9omEgLsGIX_YzIJeftJbpyCUi11g1pQ67do=.ead2d396-096d-46a5-b74c-2e602d3e7f91@github.com>
Message-ID: <qR5ZoJfHTC8KmbiuWNnuWZNW1kxKlu1F5DsMiQjZkbQ=.4d30472b-7895-48ab-af6b-80b74a47fb69@github.com>

On Thu, 27 Nov 2025 18:48:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that changes some volatile atomics to the new `Atomic` construct, fixing some issue with missing load_acquire when allocating in `G1HeapRegion::par_allocate()`.
> 
> That `load_acquire` seems necessary as when setting a new allocation region, there needs to be synchronization about the contents (top/end) of the heap region. Otherwise the allocating thread might get old/previous top values sent from the corresponding storestore (I changed to a `release_store()` in `G1AllocRegion::update_alloc_region()`.
> 
> Similar issue exists in the handling of the retained regions.
> 
> I also made the `G1AllocatorRegion::_dummy_region` Atomic; synchronization is necessary for a single `release_store` at initialization. No further synchronization is necessary (just using relaxed loads) as its contents are never changed afterwards.
> 
> Performance testing, both manually on targeted benchmarks and a few general ones without differences.
> 
> Testing: gha, tier1-3
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: ef5e744a
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef5e744a8136c3d983bdf8721a84fd1488b3c7a8
Stats:     50 lines in 3 files changed: 6 ins; 3 del; 41 mod

8372684: G1: Missing load_acquire() in G1 allocation path

Reviewed-by: kbarrett, sjohanss

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

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

From jsikstro at openjdk.org  Mon Dec  1 09:34:40 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 1 Dec 2025 09:34:40 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint
Message-ID: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>

Hello,

We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.

I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.

 uintx CardTable::ct_max_alignment_constraint() {
   // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
-  return GCCardSizeInBytes * os::vm_page_size();
+  return GCCardSizeInBytes * 64 * K;
 }


Also tested with Oracle's tier1-4.

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

Commit messages:
 - 8372747: G1: Conservative heap alignment does not account for card table constraint

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

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

From jsikstro at openjdk.org  Mon Dec  1 09:37:46 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 1 Dec 2025 09:37:46 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint
In-Reply-To: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
Message-ID: <SYddIK1pT7mdHSU063gj17FkvYOyUPiTfdU0gya-2Mw=.e7bf5156-92d1-4147-914e-b5a16049d0d0@github.com>

On Mon, 1 Dec 2025 09:26:20 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.
> 
> I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.
> 
>  uintx CardTable::ct_max_alignment_constraint() {
>    // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
> -  return GCCardSizeInBytes * os::vm_page_size();
> +  return GCCardSizeInBytes * 64 * K;
>  }
> 
> 
> Also tested with Oracle's tier1-4.

@TheRealMDoerr could you verify this at your end as well? Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/28572#issuecomment-3595510206

From stefank at openjdk.org  Mon Dec  1 09:52:47 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 1 Dec 2025 09:52:47 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder
In-Reply-To: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
Message-ID: <u-VOxTgdE3iKxRHcHiQNtX0oinVZhMuU4_aXMnXZPOY=.99988b08-9f8c-4ce1-a0b0-c270cc31482c@github.com>

On Sat, 29 Nov 2025 12:40:39 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Summary of change:
> 
> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
> 2. `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
> 3. Addition of ZGC to list of parallel collectors
> 
> Testing:
> HS Tiers 1 and 2
> Ran with all flag combinations in CI

Could we instead run with explicit test sections that list all supported GCs, similarly to what we do in `test/hotspot/jtreg/gc/TestSystemGC.java`. That way we our CI tasks that run with a specified GC also runs this test.

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

PR Comment: https://git.openjdk.org/jdk/pull/28566#issuecomment-3595583088

From mdoerr at openjdk.org  Mon Dec  1 10:05:48 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 1 Dec 2025 10:05:48 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint
In-Reply-To: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
Message-ID: <mIgRgWl0cqBBhoFEQb_t2TdmcrVLQLd9i4ijNXNH8OU=.d0538fd3-b044-4584-b6c8-99f1cab9a7fe@github.com>

On Mon, 1 Dec 2025 09:26:20 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.
> 
> I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.
> 
>  uintx CardTable::ct_max_alignment_constraint() {
>    // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
> -  return GCCardSizeInBytes * os::vm_page_size();
> +  return GCCardSizeInBytes * 64 * K;
>  }
> 
> 
> Also tested with Oracle's tier1-4.

Looks good and fixes the issue. Thanks!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28572#pullrequestreview-3524180620

From stefank at openjdk.org  Mon Dec  1 10:16:25 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 1 Dec 2025 10:16:25 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint [v2]
In-Reply-To: <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
 <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
Message-ID: <0CAC2wFrQao4QHUX0aQEgaPkqGCEot2OBlK7UU05s0E=.ca061bf4-ed8d-4113-aa55-9ab85106cf53@github.com>

On Mon, 1 Dec 2025 10:13:31 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.
>> 
>> I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.
>> 
>>  uintx CardTable::ct_max_alignment_constraint() {
>>    // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
>> -  return GCCardSizeInBytes * os::vm_page_size();
>> +  return GCCardSizeInBytes * 64 * K;
>>  }
>> 
>> 
>> Also tested with Oracle's tier1-4.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify return a bit

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28572#pullrequestreview-3524210948

From jsikstro at openjdk.org  Mon Dec  1 10:16:24 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 1 Dec 2025 10:16:24 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint [v2]
In-Reply-To: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
Message-ID: <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>

> Hello,
> 
> We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.
> 
> I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.
> 
>  uintx CardTable::ct_max_alignment_constraint() {
>    // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
> -  return GCCardSizeInBytes * os::vm_page_size();
> +  return GCCardSizeInBytes * 64 * K;
>  }
> 
> 
> Also tested with Oracle's tier1-4.

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Simplify return a bit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28572/files
  - new: https://git.openjdk.org/jdk/pull/28572/files/f0bc4359..8c8aedf2

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

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

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

From jsikstro at openjdk.org  Mon Dec  1 10:16:26 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 1 Dec 2025 10:16:26 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint [v2]
In-Reply-To: <mIgRgWl0cqBBhoFEQb_t2TdmcrVLQLd9i4ijNXNH8OU=.d0538fd3-b044-4584-b6c8-99f1cab9a7fe@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
 <mIgRgWl0cqBBhoFEQb_t2TdmcrVLQLd9i4ijNXNH8OU=.d0538fd3-b044-4584-b6c8-99f1cab9a7fe@github.com>
Message-ID: <-46t0dfW-pL7RPDTMK4__95pb7lMxmbJEGZVsh_4iI0=.34144c53-6d7d-4300-af69-c30a80c708b2@github.com>

On Mon, 1 Dec 2025 10:03:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify return a bit
>
> Looks good and fixes the issue. Thanks!

Thank you @TheRealMDoerr! I simplified the return statement a bit, the logic should be the same. Works on my end.

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

PR Comment: https://git.openjdk.org/jdk/pull/28572#issuecomment-3595701536

From tschatzl at openjdk.org  Mon Dec  1 10:30:49 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 1 Dec 2025 10:30:49 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint [v2]
In-Reply-To: <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
 <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
Message-ID: <m8cw1McRTrlaQLfdguS-av8Fhg823aSb8k2QP8MOcDk=.96ab0bfa-463c-406c-8270-d30c5338411e@github.com>

On Mon, 1 Dec 2025 10:16:24 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.
>> 
>> I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.
>> 
>>  uintx CardTable::ct_max_alignment_constraint() {
>>    // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
>> -  return GCCardSizeInBytes * os::vm_page_size();
>> +  return GCCardSizeInBytes * 64 * K;
>>  }
>> 
>> 
>> Also tested with Oracle's tier1-4.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify return a bit

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28572#pullrequestreview-3524278700

From sjohanss at openjdk.org  Mon Dec  1 10:30:50 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 1 Dec 2025 10:30:50 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint [v2]
In-Reply-To: <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
 <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
Message-ID: <DRHA8EJSf1781pRG4pvZ_dkoZf0hXYHOyphdih8Btz8=.6d73de56-7fc9-4589-b0ba-cb9112bca7e7@github.com>

On Mon, 1 Dec 2025 10:16:24 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.
>> 
>> I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.
>> 
>>  uintx CardTable::ct_max_alignment_constraint() {
>>    // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
>> -  return GCCardSizeInBytes * os::vm_page_size();
>> +  return GCCardSizeInBytes * 64 * K;
>>  }
>> 
>> 
>> Also tested with Oracle's tier1-4.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify return a bit

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28572#pullrequestreview-3524279110

From sjohanss at openjdk.org  Mon Dec  1 10:34:02 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 1 Dec 2025 10:34:02 GMT
Subject: RFR: 8372610: G1: JDK-8297692 broke code roots scan measurements
 [v2]
In-Reply-To: <Ano50_YS53N5kDZljBT7gYOTafOBRZ5Fc_o-JtMjiqk=.6a915879-12c8-4165-b45a-f3186b45c2de@github.com>
References: <E-jR8ppAXF9-WTqjwM_YzZLfnl2XOj8kXt-IiV9JxVE=.d548a906-68df-4238-b563-178281a4423d@github.com>
 <Ano50_YS53N5kDZljBT7gYOTafOBRZ5Fc_o-JtMjiqk=.6a915879-12c8-4165-b45a-f3186b45c2de@github.com>
Message-ID: <JBVD0bGnxuxiVjGdX2F9DBgXA4zlZFIuaCEtNiQlgWA=.c7a01c94-1a4d-4e9e-8b41-4cf4d53c7f38@github.com>

On Thu, 27 Nov 2025 16:27:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that fixes "Code Root Scan" logging - a wrong scope for the timing measurements made these values always print `0.00` and the duration moved to the "Other time" category.
>> 
>> E.g. without patch:
>> 
>> 
>> [1.121s][debug][gc,phases] GC(7)     Code Root Scan (ms):           Min: 0.00, Avg: 0.00, Max: 0.00, Diff: 0.00, Sum: 0.00, Workers: 4
>> [1.485s][debug][gc,phases] GC(8)     Code Root Scan (ms):           Min: 0.00, Avg: 0.00, Max: 0.00, Diff: 0.00, Sum: 0.00, Workers: 8
>> [1.715s][debug][gc,phases] GC(9)     Code Root Scan (ms):           Min: 0.00, Avg: 0.00, Max: 0.00, Diff: 0.00, Sum: 0.00, Workers: 8
>> 
>> 
>> with patch:
>> 
>> 
>> [1.392s][debug][gc,phases] GC(7)     Code Root Scan (ms):           Min: 0.00, Avg: 0.03, Max: 0.12, Diff: 0.12, Sum: 0.21, Workers: 8
>> [1.638s][debug][gc,phases] GC(8)     Code Root Scan (ms):           Min: 0.00, Avg: 0.03, Max: 0.15, Diff: 0.15, Sum: 0.26, Workers: 8
>> [1.862s][debug][gc,phases] GC(9)     Code Root Scan (ms):           Min: 0.00, Avg: 0.03, Max: 0.16, Diff: 0.15, Sum: 0.26, Workers: 8
>> 
>> 
>> Testing: gha, local checking
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * reformatting

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28513#pullrequestreview-3524291494

From aboldtch at openjdk.org  Mon Dec  1 11:00:15 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 1 Dec 2025 11:00:15 GMT
Subject: RFR: 8372540: SerialGC: Remove race between allocation and expansion
 before is_init_completed
Message-ID: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>

JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 

We have currently observed one crash related to the fact that top is updated before we setup the card table.  But we can also see that the synchronisation between expansion and allocation is not correct. 

I propose that we create a critical section for the early expansion and any early allocation. 

We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.

_We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 

* Testing
  * GHA
  * Tier 1-3 on Oracle supported platforms

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

Commit messages:
 - 8372540: SerialGC: Remove race between allocation and expansion before is_init_completed

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

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

From aboldtch at openjdk.org  Mon Dec  1 11:00:33 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 1 Dec 2025 11:00:33 GMT
Subject: RFR: 8372645: ParallelGC: Remove race between allocation and expansion
 before is_init_completed
Message-ID: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>

JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 

We have currently observed one crash related to the fact that top is updated before we setup the card table. 

I propose that we create a critical section for the early expansion and any early allocation. 

We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.

_We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 

* Testing
  * GHA
  * Tier 1-3 on Oracle supported platforms

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

Commit messages:
 - 8372645: ParallelGC: Remove race between allocation and expansion before is_init_completed

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

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

From mdoerr at openjdk.org  Mon Dec  1 11:13:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 1 Dec 2025 11:13:02 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint [v2]
In-Reply-To: <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
 <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
Message-ID: <FIV04vVXiZxfjGx9kO2Yz8n6EZ_9IS-EGQMfpMQDUz8=.88e2e16e-1ccd-45ed-8a26-ee0f131b2d53@github.com>

On Mon, 1 Dec 2025 10:16:24 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.
>> 
>> I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.
>> 
>>  uintx CardTable::ct_max_alignment_constraint() {
>>    // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
>> -  return GCCardSizeInBytes * os::vm_page_size();
>> +  return GCCardSizeInBytes * 64 * K;
>>  }
>> 
>> 
>> Also tested with Oracle's tier1-4.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify return a bit

Still good.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28572#pullrequestreview-3524428131

From tschatzl at openjdk.org  Mon Dec  1 11:30:59 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 1 Dec 2025 11:30:59 GMT
Subject: RFR: 8372610: G1: JDK-8297692 broke code roots scan measurements
 [v2]
In-Reply-To: <JBVD0bGnxuxiVjGdX2F9DBgXA4zlZFIuaCEtNiQlgWA=.c7a01c94-1a4d-4e9e-8b41-4cf4d53c7f38@github.com>
References: <E-jR8ppAXF9-WTqjwM_YzZLfnl2XOj8kXt-IiV9JxVE=.d548a906-68df-4238-b563-178281a4423d@github.com>
 <Ano50_YS53N5kDZljBT7gYOTafOBRZ5Fc_o-JtMjiqk=.6a915879-12c8-4165-b45a-f3186b45c2de@github.com>
 <JBVD0bGnxuxiVjGdX2F9DBgXA4zlZFIuaCEtNiQlgWA=.c7a01c94-1a4d-4e9e-8b41-4cf4d53c7f38@github.com>
Message-ID: <ZzcdnsxeBDuJ2osaO9HxBG4IeDOzZFR6ZGfXngogGV4=.ea1fabeb-83c2-4f6d-b8da-96aefbb3b499@github.com>

On Mon, 1 Dec 2025 10:31:21 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * reformatting
>
> Marked as reviewed by sjohanss (Reviewer).

Thanks @kstefanj @walulyai for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/28513#issuecomment-3596017840

From tschatzl at openjdk.org  Mon Dec  1 11:31:00 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 1 Dec 2025 11:31:00 GMT
Subject: Integrated: 8372610: G1: JDK-8297692 broke code roots scan
 measurements
In-Reply-To: <E-jR8ppAXF9-WTqjwM_YzZLfnl2XOj8kXt-IiV9JxVE=.d548a906-68df-4238-b563-178281a4423d@github.com>
References: <E-jR8ppAXF9-WTqjwM_YzZLfnl2XOj8kXt-IiV9JxVE=.d548a906-68df-4238-b563-178281a4423d@github.com>
Message-ID: <cYwJbL87Buwzn05w-ZHUzeN8AxUt92V2qTCXQpQdC7o=.56503863-5c7b-4c4c-a3d9-8bc04747bc60@github.com>

On Wed, 26 Nov 2025 16:35:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes "Code Root Scan" logging - a wrong scope for the timing measurements made these values always print `0.00` and the duration moved to the "Other time" category.
> 
> E.g. without patch:
> 
> 
> [1.121s][debug][gc,phases] GC(7)     Code Root Scan (ms):           Min: 0.00, Avg: 0.00, Max: 0.00, Diff: 0.00, Sum: 0.00, Workers: 4
> [1.485s][debug][gc,phases] GC(8)     Code Root Scan (ms):           Min: 0.00, Avg: 0.00, Max: 0.00, Diff: 0.00, Sum: 0.00, Workers: 8
> [1.715s][debug][gc,phases] GC(9)     Code Root Scan (ms):           Min: 0.00, Avg: 0.00, Max: 0.00, Diff: 0.00, Sum: 0.00, Workers: 8
> 
> 
> with patch:
> 
> 
> [1.392s][debug][gc,phases] GC(7)     Code Root Scan (ms):           Min: 0.00, Avg: 0.03, Max: 0.12, Diff: 0.12, Sum: 0.21, Workers: 8
> [1.638s][debug][gc,phases] GC(8)     Code Root Scan (ms):           Min: 0.00, Avg: 0.03, Max: 0.15, Diff: 0.15, Sum: 0.26, Workers: 8
> [1.862s][debug][gc,phases] GC(9)     Code Root Scan (ms):           Min: 0.00, Avg: 0.03, Max: 0.16, Diff: 0.15, Sum: 0.26, Workers: 8
> 
> 
> Testing: gha, local checking
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 160148cc
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/160148cc7b0c2774e7aa5fece653e41c9fa7c970
Stats:     15 lines in 1 file changed: 7 ins; 6 del; 2 mod

8372610: G1: JDK-8297692 broke code roots scan measurements

Reviewed-by: iwalulya, sjohanss

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

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

From shade at openjdk.org  Mon Dec  1 12:37:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Dec 2025 12:37:46 GMT
Subject: RFR: 8342175: MemoryEaterMT fails intermittently with
 ExceptionInInitializerError
In-Reply-To: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
References: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
Message-ID: <KI9ThDtmswN-5-Lz8vB2RPt4VC4VO4_2zKulUzXKHtI=.eb9dac3c-9911-41dc-b9ee-575dc91700e5@github.com>

On Thu, 27 Nov 2025 10:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See issue for more bread-crumbs. I think this is generally a test bug for vmTestbase GC tests that run on the brink of OOME. `MemoryEaterMT` intermittently fails with Shenandoah and G1 on our machines. So I believe we should fix this as testbug.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with `-XX:+UseShenandoahGC`, 10x, now passes 
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with default (G1) GC, 10x, now passes
>  - [x] Linux AArch64 server fastdebug, `all` with default (G1) GC, still passes

@lmesnik, @tschatzl -- might be of interest for you :)

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

PR Comment: https://git.openjdk.org/jdk/pull/28531#issuecomment-3596333918

From ayang at openjdk.org  Mon Dec  1 14:39:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 1 Dec 2025 14:39:10 GMT
Subject: RFR: 8372645: ParallelGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
References: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
Message-ID: <2PTjW2YMm4c_Q5N3hGpXguNRpYjZT6sCs38N9Wi2mfQ=.e7a75237-d917-4ff4-9a3e-c855c6f5cf4f@github.com>

On Mon, 1 Dec 2025 10:52:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28574#pullrequestreview-3525319846

From ayang at openjdk.org  Mon Dec  1 14:40:18 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 1 Dec 2025 14:40:18 GMT
Subject: RFR: 8372540: SerialGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
References: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
Message-ID: <GGc-N3dTM3CwC1SaHzlX8abhRmbqmq4LOQjuXUokiMg=.80eda475-f006-440c-b0eb-a96f48196d34@github.com>

On Mon, 1 Dec 2025 10:52:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table.  But we can also see that the synchronisation between expansion and allocation is not correct. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28573#pullrequestreview-3525321583

From sjohanss at openjdk.org  Mon Dec  1 14:42:29 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 1 Dec 2025 14:42:29 GMT
Subject: RFR: 8372645: ParallelGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
References: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
Message-ID: <qVBR-MtYjXtZAQpAee9Xw0pe13nu1Njp3c97__QWxgI=.2e1f441a-a4e8-46d4-b0de-1625c2eace11@github.com>

On Mon, 1 Dec 2025 10:52:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms

Looks good, thanks for handling this.

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

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28574#pullrequestreview-3525336239

From sjohanss at openjdk.org  Mon Dec  1 14:43:33 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 1 Dec 2025 14:43:33 GMT
Subject: RFR: 8372540: SerialGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
References: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
Message-ID: <ziencTmNwFa7tJHvxVNcb8f4tFICe3QYfBct3mOdiLY=.5b670309-1b7c-489e-9941-4b47db312689@github.com>

On Mon, 1 Dec 2025 10:52:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table.  But we can also see that the synchronisation between expansion and allocation is not correct. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28573#pullrequestreview-3525342381

From lmesnik at openjdk.org  Mon Dec  1 15:39:10 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 1 Dec 2025 15:39:10 GMT
Subject: RFR: 8342175: MemoryEaterMT fails intermittently with
 ExceptionInInitializerError
In-Reply-To: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
References: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
Message-ID: <rkj2rtT0Ld3IqHJbxr5V_0f5UhwScuaoeOGHcs8zLN4=.094f42b5-ab9e-4768-be4a-e064aa0c4e84@github.com>

On Thu, 27 Nov 2025 10:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See issue for more bread-crumbs. I think this is generally a test bug for vmTestbase GC tests that run on the brink of OOME. `MemoryEaterMT` intermittently fails with Shenandoah and G1 on our machines. So I believe we should fix this as testbug.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with `-XX:+UseShenandoahGC`, 10x, now passes 
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with default (G1) GC, 10x, now passes
>  - [x] Linux AArch64 server fastdebug, `all` with default (G1) GC, still passes

Thanks for fixing these tests. Make sense to minimize allocation during OOME.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28531#pullrequestreview-3525664864

From wkemper at openjdk.org  Mon Dec  1 15:40:34 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 1 Dec 2025 15:40:34 GMT
Subject: Integrated: 8372444: Genshen: Optimize evacuation function
In-Reply-To: <aGv_WnWriDJYrM05-_E2zrDKUgtP008JSpCiUIUmxqs=.04e8c1e5-6de7-471a-808f-10b1e4e51974@github.com>
References: <aGv_WnWriDJYrM05-_E2zrDKUgtP008JSpCiUIUmxqs=.04e8c1e5-6de7-471a-808f-10b1e4e51974@github.com>
Message-ID: <2aym_7c9MkBuruXbGMpz4DjKubklrkrf_U7w_Yc81Ck=.3fe75278-3246-48bb-8c28-7de179adadb0@github.com>

On Tue, 25 Nov 2025 17:33:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a hot code path. Many of the branches can be eliminated at compile time by introducing template parameters. This change shows a 5% reduction in concurrent evacuation times at the trimmed-10 average on the extremem benchmark:
> 
> 
> gen/control/extremem
>                                 Category |  Count |         Total |      GeoMean |      Average |     Trim 0.1 |       StdDev |      Minimum |      Maximum
>         concurrent_evacuation_young_data |     65 |   9625198.000 |   118747.249 |   148079.969 |   145182.189 |    76534.845 |     7216.000 |   317261.000
> 
> gen/template/extremem
>                                 Category |  Count |         Total |      GeoMean |      Average |     Trim 0.1 |       StdDev |      Minimum |      Maximum
>         concurrent_evacuation_young_data |     65 |   9095084.000 |   113036.539 |   139924.369 |   137661.226 |    71091.273 |     7523.000 |   294442.000

This pull request has now been integrated.

Changeset: a1cc8f4e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1cc8f4e4107e361f64cf51ff73985e471cdde03
Stats:     54 lines in 5 files changed: 15 ins; 13 del; 26 mod

8372444: Genshen: Optimize evacuation function

Reviewed-by: ysr, xpeng

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

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

From wkemper at openjdk.org  Mon Dec  1 15:40:32 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 1 Dec 2025 15:40:32 GMT
Subject: RFR: 8372444: Genshen: Optimize evacuation function
In-Reply-To: <1H7ReDFaqSzRUxHiPQgoHwqr9nGnieCTkypgz2m5Z4I=.0bfbe08e-c85f-4ad0-805e-d94c709057d1@github.com>
References: <aGv_WnWriDJYrM05-_E2zrDKUgtP008JSpCiUIUmxqs=.04e8c1e5-6de7-471a-808f-10b1e4e51974@github.com>
 <1H7ReDFaqSzRUxHiPQgoHwqr9nGnieCTkypgz2m5Z4I=.0bfbe08e-c85f-4ad0-805e-d94c709057d1@github.com>
Message-ID: <zYUd7Vyil54osLG-uRA2VO_mU4asu-wMVGhwGesg8cM=.2178180e-1750-44d6-a3e7-1cf62b6e5390@github.com>

On Wed, 26 Nov 2025 02:13:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> This is a hot code path. Many of the branches can be eliminated at compile time by introducing template parameters. This change shows a 5% reduction in concurrent evacuation times at the trimmed-10 average on the extremem benchmark:
>> 
>> 
>> gen/control/extremem
>>                                 Category |  Count |         Total |      GeoMean |      Average |     Trim 0.1 |       StdDev |      Minimum |      Maximum
>>         concurrent_evacuation_young_data |     65 |   9625198.000 |   118747.249 |   148079.969 |   145182.189 |    76534.845 |     7216.000 |   317261.000
>> 
>> gen/template/extremem
>>                                 Category |  Count |         Total |      GeoMean |      Average |     Trim 0.1 |       StdDev |      Minimum |      Maximum
>>         concurrent_evacuation_young_data |     65 |   9095084.000 |   113036.539 |   139924.369 |   137661.226 |    71091.273 |     7523.000 |   294442.000
>
> LGTM. Impressed that templatization led to such a substantial improvement.
> Should the 2-case switch in `ShenandoahGenerationalHeap::evacuate_object()` be converted to an `if-else` ?

@ysramakrishna , we have had reviewers in the past ask us to use a switch with this enumeration. I agree an `if/else` would be more compact here, but it would probably belong on a different pull request. Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28496#issuecomment-3597245231

From eosterlund at openjdk.org  Mon Dec  1 16:03:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 1 Dec 2025 16:03:27 GMT
Subject: RFR: 8372540: SerialGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
References: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
Message-ID: <FZ0D_IERr_Km1iylmkSlb1rxiD9ofGBcrLrxE_WD-j8=.05abfa15-25af-4ac7-849a-9036ef42ebf8@github.com>

On Mon, 1 Dec 2025 10:52:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table.  But we can also see that the synchronisation between expansion and allocation is not correct. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms
>   * Stress-tested with reproducer `while java -XX:-UseCompressedOops -XX:+UseSerialGC -XX:InitialHeapSize=1m -Xmx1002M -version; do date;`

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28573#pullrequestreview-3525783112

From eosterlund at openjdk.org  Mon Dec  1 16:04:34 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 1 Dec 2025 16:04:34 GMT
Subject: RFR: 8372645: ParallelGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
References: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
Message-ID: <ZVsBKPRrKMfavd0syJGH7cyl3IF7-nL3VKCYTL70CCY=.b9ef5f08-d190-4098-a3a7-dbd1cf152d34@github.com>

On Mon, 1 Dec 2025 10:52:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms
>   * Stress-tested with reproducer `while java -XX:-UseCompressedOops -XX:+UseParallelGC -XX:InitialHeapSize=1m -Xmx1002M -version; do date;`

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28574#pullrequestreview-3525786577

From ysr at openjdk.org  Mon Dec  1 16:34:40 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 1 Dec 2025 16:34:40 GMT
Subject: RFR: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667
In-Reply-To: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
Message-ID: <4h1gCnsTk4_Gbl77bm_oe2S5deR7LGajZmvsPcDV5dw=.b29abfd8-1649-433f-b392-f959e63a817c@github.com>

On Thu, 27 Nov 2025 03:10:18 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> For non-plab allocs in old gen, the objects need to be registered in card table, which was missed in the [PR](https://git.openjdk.org/jdk/pull/28247) for JDK-8371667. The bug didn't cause jtreg test failures in GHA and my local test, but when I ran specjbb benchmarks, it did cause crash at ShenandoahScanRemembered::process_clusters when GC scans remembered set. 
> 
> The bug may cause other issue since the object in old gen is not properly registered, e.g. marking phase have wrong result.
> 
> Tests:
> - [x]  specjbb, no crash
> - [x] hotspot_gc_shenandoah

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28521#pullrequestreview-3525935185

From wkemper at openjdk.org  Mon Dec  1 16:37:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 1 Dec 2025 16:37:40 GMT
Subject: RFR: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667
In-Reply-To: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
Message-ID: <kp8EYxFjqY_Y5V3Lzq0sRIMpJWkN9btp4QK-Zj16Ppg=.5b39a8c1-5279-474b-ac1e-046933c79d45@github.com>

On Thu, 27 Nov 2025 03:10:18 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> For non-plab allocs in old gen, the objects need to be registered in card table, which was missed in the [PR](https://git.openjdk.org/jdk/pull/28247) for JDK-8371667. The bug didn't cause jtreg test failures in GHA and my local test, but when I ran specjbb benchmarks, it did cause crash at ShenandoahScanRemembered::process_clusters when GC scans remembered set. 
> 
> The bug may cause other issue since the object in old gen is not properly registered, e.g. marking phase have wrong result.
> 
> Tests:
> - [x]  specjbb, no crash
> - [x] hotspot_gc_shenandoah

Given that https://github.com/openjdk/jdk/pull/28247 significantly changed the encoding of the request `type` here, and we already missed an incorrect usage in one spot, I think we should use the member function to test for a shared/lab allocation. Can we also check if there are other uses of `type()` that may not be safe now?

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28521#pullrequestreview-3525951105

From xpeng at openjdk.org  Mon Dec  1 16:44:27 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 1 Dec 2025 16:44:27 GMT
Subject: RFR: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667
In-Reply-To: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
Message-ID: <ML1mPdpTzaOC9Fckn3tGLw6VAJ4tR3vvQQ3fJcTmzp0=.cf9bbefb-5db8-4d25-a5aa-31000deb485f@github.com>

On Thu, 27 Nov 2025 03:10:18 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> For non-plab allocs in old gen, the objects need to be registered in card table, which was missed in the [PR](https://git.openjdk.org/jdk/pull/28247) for JDK-8371667. The bug didn't cause jtreg test failures in GHA and my local test, but when I ran specjbb benchmarks, it did cause crash at ShenandoahScanRemembered::process_clusters when GC scans remembered set. 
> 
> The bug may cause other issue since the object in old gen is not properly registered, e.g. marking phase have wrong result.
> 
> Tests:
> - [x]  specjbb, no crash
> - [x] hotspot_gc_shenandoah

> Given that #28247 significantly changed the encoding of the request `type` here, and we already missed an incorrect usage in one spot, I think we should use the member function to test for a shared/lab allocation. Can we also check if there are other uses of `type()` that may not be safe now?

I did briefly check all the places where `type()` is called, it should be good now, there are two more places we could improve but won't causes bug, I initially added them in the PR and decided to revert them since they are not related to this bug fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/28521#issuecomment-3597622168

From xpeng at openjdk.org  Mon Dec  1 16:59:16 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 1 Dec 2025 16:59:16 GMT
Subject: RFR: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667 [v2]
In-Reply-To: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
Message-ID: <6Y104R2wl_Z1TSFnYaYXRQdOzZGCCxXigrwBK8RM_r4=.265e3f37-88ff-4189-865b-8c17b6b8317a@github.com>

> For non-plab allocs in old gen, the objects need to be registered in card table, which was missed in the [PR](https://git.openjdk.org/jdk/pull/28247) for JDK-8371667. The bug didn't cause jtreg test failures in GHA and my local test, but when I ran specjbb benchmarks, it did cause crash at ShenandoahScanRemembered::process_clusters when GC scans remembered set. 
> 
> The bug may cause other issue since the object in old gen is not properly registered, e.g. marking phase have wrong result.
> 
> Tests:
> - [x]  specjbb, no crash
> - [x] hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Use member function is_lab_alloc() instead of test the value of type()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28521/files
  - new: https://git.openjdk.org/jdk/pull/28521/files/24dae41f..ad82a691

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

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

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

From xpeng at openjdk.org  Mon Dec  1 16:59:18 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 1 Dec 2025 16:59:18 GMT
Subject: RFR: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667
In-Reply-To: <ML1mPdpTzaOC9Fckn3tGLw6VAJ4tR3vvQQ3fJcTmzp0=.cf9bbefb-5db8-4d25-a5aa-31000deb485f@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
 <ML1mPdpTzaOC9Fckn3tGLw6VAJ4tR3vvQQ3fJcTmzp0=.cf9bbefb-5db8-4d25-a5aa-31000deb485f@github.com>
Message-ID: <igZ6hGz3SgePmsn_WVyI3Zgrshqlb6oEaAvscm3sNqw=.8beea26d-899b-44fa-a85e-691342a1c1d2@github.com>

On Mon, 1 Dec 2025 16:42:16 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Given that #28247 significantly changed the encoding of the request `type` here, and we already missed an incorrect usage in one spot, I think we should use the member function to test for a shared/lab allocation. Can we also check if there are other uses of `type()` that may not be safe now?

I have updated the PR to use the member function to test for a shared/lab allocation, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/28521#issuecomment-3597721121

From wkemper at openjdk.org  Mon Dec  1 17:26:26 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 1 Dec 2025 17:26:26 GMT
Subject: RFR: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667 [v2]
In-Reply-To: <6Y104R2wl_Z1TSFnYaYXRQdOzZGCCxXigrwBK8RM_r4=.265e3f37-88ff-4189-865b-8c17b6b8317a@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
 <6Y104R2wl_Z1TSFnYaYXRQdOzZGCCxXigrwBK8RM_r4=.265e3f37-88ff-4189-865b-8c17b6b8317a@github.com>
Message-ID: <Z5e0ckjnB7QzoCQlJJnrqBwMTgh2bYTx8BN_y4uqn8Y=.af051134-6ff6-4485-9fbd-4666d1e57cf7@github.com>

On Mon, 1 Dec 2025 16:59:16 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> For non-plab allocs in old gen, the objects need to be registered in card table, which was missed in the [PR](https://git.openjdk.org/jdk/pull/28247) for JDK-8371667. The bug didn't cause jtreg test failures in GHA and my local test, but when I ran specjbb benchmarks, it did cause crash at ShenandoahScanRemembered::process_clusters when GC scans remembered set. 
>> 
>> The bug may cause other issue since the object in old gen is not properly registered, e.g. marking phase have wrong result.
>> 
>> Tests:
>> - [x]  specjbb, no crash
>> - [x] hotspot_gc_shenandoah
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use member function is_lab_alloc() instead of test the value of type()

Thank you. I think we should try to remove other uses of `type()` in a separate PR.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28521#pullrequestreview-3526162449

From xpeng at openjdk.org  Mon Dec  1 17:31:28 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 1 Dec 2025 17:31:28 GMT
Subject: RFR: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667 [v2]
In-Reply-To: <Z5e0ckjnB7QzoCQlJJnrqBwMTgh2bYTx8BN_y4uqn8Y=.af051134-6ff6-4485-9fbd-4666d1e57cf7@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
 <6Y104R2wl_Z1TSFnYaYXRQdOzZGCCxXigrwBK8RM_r4=.265e3f37-88ff-4189-865b-8c17b6b8317a@github.com>
 <Z5e0ckjnB7QzoCQlJJnrqBwMTgh2bYTx8BN_y4uqn8Y=.af051134-6ff6-4485-9fbd-4666d1e57cf7@github.com>
Message-ID: <KtlRZCUehL2oxqzteQToLQVNeMiFi59peKwn6i3ENxA=.35019bc9-28f5-4ccc-bf13-b970a90c0607@github.com>

On Mon, 1 Dec 2025 17:23:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Thank you. I think we should try to remove other uses of `type()` in a separate PR.

Thanks, I'll see if we can remove it, I believe we should be able to remove it from all the places except logging.

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

PR Comment: https://git.openjdk.org/jdk/pull/28521#issuecomment-3597890180

From xpeng at openjdk.org  Mon Dec  1 18:30:48 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 1 Dec 2025 18:30:48 GMT
Subject: RFR: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667 [v2]
In-Reply-To: <6Y104R2wl_Z1TSFnYaYXRQdOzZGCCxXigrwBK8RM_r4=.265e3f37-88ff-4189-865b-8c17b6b8317a@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
 <6Y104R2wl_Z1TSFnYaYXRQdOzZGCCxXigrwBK8RM_r4=.265e3f37-88ff-4189-865b-8c17b6b8317a@github.com>
Message-ID: <hLF8iL0C2wWQAzvASOHriOmlyAXDUayOs2ioq1GqKlU=.4a9cd6c7-d72f-4372-bfd2-d3e5f893b988@github.com>

On Mon, 1 Dec 2025 16:59:16 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> For non-plab allocs in old gen, the objects need to be registered in card table, which was missed in the [PR](https://git.openjdk.org/jdk/pull/28247) for JDK-8371667. The bug didn't cause jtreg test failures in GHA and my local test, but when I ran specjbb benchmarks, it did cause crash at ShenandoahScanRemembered::process_clusters when GC scans remembered set. 
>> 
>> The bug may cause other issue since the object in old gen is not properly registered, e.g. marking phase have wrong result.
>> 
>> Tests:
>> - [x]  specjbb, no crash
>> - [x] hotspot_gc_shenandoah
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use member function is_lab_alloc() instead of test the value of type()

Thanks all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28521#issuecomment-3598205309

From xpeng at openjdk.org  Mon Dec  1 18:34:02 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 1 Dec 2025 18:34:02 GMT
Subject: Integrated: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667
In-Reply-To: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
Message-ID: <FgIpmdimY5uHzr4QzrS-wD1ONC5oAfTOitkj-FlsBlo=.07d2624f-327b-4e31-b89a-3ed827c9cda3@github.com>

On Thu, 27 Nov 2025 03:10:18 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> For non-plab allocs in old gen, the objects need to be registered in card table, which was missed in the [PR](https://git.openjdk.org/jdk/pull/28247) for JDK-8371667. The bug didn't cause jtreg test failures in GHA and my local test, but when I ran specjbb benchmarks, it did cause crash at ShenandoahScanRemembered::process_clusters when GC scans remembered set. 
> 
> The bug may cause other issue since the object in old gen is not properly registered, e.g. marking phase have wrong result.
> 
> Tests:
> - [x]  specjbb, no crash
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 79e99bb0
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79e99bb0778608733a677821a0bb35041e9fb939
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8372566: Genshen: crash at ShenandoahScanRemembered::process_clusters after JDK-8371667

Reviewed-by: wkemper, kdnilsen, ysr

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

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

From aboldtch at openjdk.org  Tue Dec  2 08:12:48 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 2 Dec 2025 08:12:48 GMT
Subject: RFR: 8342175: MemoryEaterMT fails intermittently with
 ExceptionInInitializerError
In-Reply-To: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
References: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
Message-ID: <LRZmoYX-9I-iGQXsdpuOfjbHVrTu5GJzIlseHGxSjdY=.e89a9e3f-bd1e-4c28-8521-8627ef3011a7@github.com>

On Thu, 27 Nov 2025 10:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See issue for more bread-crumbs. I think this is generally a test bug for vmTestbase GC tests that run on the brink of OOME. `MemoryEaterMT` intermittently fails with Shenandoah and G1 on our machines. So I believe we should fix this as testbug.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with `-XX:+UseShenandoahGC`, 10x, now passes 
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with default (G1) GC, 10x, now passes
>  - [x] Linux AArch64 server fastdebug, `all` with default (G1) GC, still passes

Looks good. Thanks you for fixing.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28531#pullrequestreview-3528784118

From aboldtch at openjdk.org  Tue Dec  2 08:39:48 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 2 Dec 2025 08:39:48 GMT
Subject: RFR: 8372564: Convert StringDedup to use Atomic<T>
In-Reply-To: <voobFETMOEBS-cmAzhAZTo5Gv2vAUARRELQAUyEF9Zk=.309cf890-2d32-4e0b-8f52-dc7f1610b314@github.com>
References: <voobFETMOEBS-cmAzhAZTo5Gv2vAUARRELQAUyEF9Zk=.309cf890-2d32-4e0b-8f52-dc7f1610b314@github.com>
Message-ID: <iOuGDyWZxhs11NwzIwazTM0UjDLAK1NkRZk75bgK7m4=.f9de3c91-1af9-42cd-8dba-5f6368260c5a@github.com>

On Thu, 27 Nov 2025 08:18:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to StringDedup to use Atomic rather than directly
> applying AtomicAccess to volatile members.
> 
> Testing: mach5 tier1-5

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

> 54: 
> 55:   static OopStorage* _storages[2];
> 56:   static DeferredStatic<Atomic<StorageUse*>> _storage_for_requests;

What is the reason for the `DeferredStatic`?

Is it just for the init once semantics and asserts?

_Is this a style we should adapt more broadly for our init once static variables?_

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28524#discussion_r2580179792

From shade at openjdk.org  Tue Dec  2 08:41:04 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Dec 2025 08:41:04 GMT
Subject: RFR: 8342175: MemoryEaterMT fails intermittently with
 ExceptionInInitializerError
In-Reply-To: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
References: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
Message-ID: <x1juKHDDEcBkEw1_3Os7jx0YS5baKaT_vASM49c2vWo=.34672dc0-8c4c-4a8d-ab78-31e8c997b6eb@github.com>

On Thu, 27 Nov 2025 10:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See issue for more bread-crumbs. I think this is generally a test bug for vmTestbase GC tests that run on the brink of OOME. `MemoryEaterMT` intermittently fails with Shenandoah and G1 on our machines. So I believe we should fix this as testbug.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with `-XX:+UseShenandoahGC`, 10x, now passes 
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with default (G1) GC, 10x, now passes
>  - [x] Linux AArch64 server fastdebug, `all` with default (G1) GC, still passes

Thanks for reviews! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/28531#issuecomment-3600851095

From shade at openjdk.org  Tue Dec  2 08:41:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Dec 2025 08:41:05 GMT
Subject: Integrated: 8342175: MemoryEaterMT fails intermittently with
 ExceptionInInitializerError
In-Reply-To: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
References: <7yxbhV3pDyiQOMHN4tPQ4ZblXc6I2RFEC4vSosjH7ic=.8a578204-2513-429a-9018-32e6dd2256be@github.com>
Message-ID: <5Vpo-eCNyshcWvZhm4xHyzSU37czfOB5H6MzKD9hBEE=.d9d7ed86-b717-4037-96dd-671fb096ac67@github.com>

On Thu, 27 Nov 2025 10:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See issue for more bread-crumbs. I think this is generally a test bug for vmTestbase GC tests that run on the brink of OOME. `MemoryEaterMT` intermittently fails with Shenandoah and G1 on our machines. So I believe we should fix this as testbug.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with `-XX:+UseShenandoahGC`, 10x, now passes 
>  - [x] Linux AArch64 server fastdebug, `MemoryEaterMT` with default (G1) GC, 10x, now passes
>  - [x] Linux AArch64 server fastdebug, `all` with default (G1) GC, still passes

This pull request has now been integrated.

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

8342175: MemoryEaterMT fails intermittently with ExceptionInInitializerError

Reviewed-by: lmesnik, aboldtch

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

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

From rsunderbabu at openjdk.org  Tue Dec  2 08:56:28 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 2 Dec 2025 08:56:28 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
Message-ID: <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>

> Summary of change:
> 
> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
> 2. `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
> 3. Addition of ZGC to list of parallel collectors
> 
> Testing:
> HS Tiers 1 and 2
> Ran with all flag combinations in CI

Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:

  separating test sections

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28566/files
  - new: https://git.openjdk.org/jdk/pull/28566/files/74e72e0b..e10d268d

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

  Stats: 109 lines in 1 file changed: 62 ins; 23 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/28566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28566/head:pull/28566

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

From aboldtch at openjdk.org  Tue Dec  2 10:59:23 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 2 Dec 2025 10:59:23 GMT
Subject: RFR: 8372540: SerialGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
References: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
Message-ID: <ilb9sfj0AC8BkTeCf0ROhBlg2YWJ0ugG2i1tqmkadTs=.428fc53c-38c0-42de-b74f-8a972675151b@github.com>

On Mon, 1 Dec 2025 10:52:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table.  But we can also see that the synchronisation between expansion and allocation is not correct. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms
>   * Stress-tested with reproducer `while java -XX:-UseCompressedOops -XX:+UseSerialGC -XX:InitialHeapSize=1m -Xmx1002M -version; do date;`

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28573#issuecomment-3601431365

From aboldtch at openjdk.org  Tue Dec  2 11:02:02 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 2 Dec 2025 11:02:02 GMT
Subject: Integrated: 8372540: SerialGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
References: <8eF24-efC3asnPPQeCYcWfpfnuN2jBlE-bE5qO9z308=.19fb9637-1db4-4370-9d98-e347172d870a@github.com>
Message-ID: <LYmrGoRhTeSQ8P6YH0zHot3F9GcG_VhkzLKMDXgNVyQ=.77454085-61c2-433f-afe2-ad9ff7a57f66@github.com>

On Mon, 1 Dec 2025 10:52:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table.  But we can also see that the synchronisation between expansion and allocation is not correct. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms
>   * Stress-tested with reproducer `while java -XX:-UseCompressedOops -XX:+UseSerialGC -XX:InitialHeapSize=1m -Xmx1002M -version; do date;`

This pull request has now been integrated.

Changeset: e27abe8a
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e27abe8a979880f308c69ea53319565dcd2142b6
Stats:     15 lines in 1 file changed: 8 ins; 0 del; 7 mod

8372540: SerialGC: Remove race between allocation and expansion before is_init_completed

Reviewed-by: ayang, sjohanss, eosterlund

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

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

From aboldtch at openjdk.org  Tue Dec  2 11:02:02 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 2 Dec 2025 11:02:02 GMT
Subject: RFR: 8372645: ParallelGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
References: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
Message-ID: <5e_xWKmJoMfoKEe1eA5xumi-UXS4eCrGY_YLamXfuHk=.5d49fb1e-ace5-453a-a44a-528e753dcb49@github.com>

On Mon, 1 Dec 2025 10:52:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms
>   * Stress-tested with reproducer `while java -XX:-UseCompressedOops -XX:+UseParallelGC -XX:InitialHeapSize=1m -Xmx1002M -version; do date;`

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28574#issuecomment-3601432274

From aboldtch at openjdk.org  Tue Dec  2 11:02:02 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 2 Dec 2025 11:02:02 GMT
Subject: Integrated: 8372645: ParallelGC: Remove race between allocation and
 expansion before is_init_completed
In-Reply-To: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
References: <mt2gy57bdUpMeJj5zAmpVjpfD5lRPtcMhjrh5f4xDuI=.fbdec70f-e657-44b5-a96d-7ae6b909257c@github.com>
Message-ID: <M2TgtkaE1sVYckZxbRnZNE1TklsQXCAfya4CByx6Pp4=.5916bd46-dc3f-4fa7-8ff8-9cee03157759@github.com>

On Mon, 1 Dec 2025 10:52:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before `is_init_completed`). The expansion code was written with the assumption that it is performed in a safepoint. 
> 
> We have currently observed one crash related to the fact that top is updated before we setup the card table. 
> 
> I propose that we create a critical section for the early expansion and any early allocation. 
> 
> We might want to relax this critical section in the future, after we have fixed the expansion code and allocation interactions. But for now it seems safer to simply use a mutex.
> 
> _We also looked at using a RW style lock, but deemed it a bit unnecessary (https://github.com/openjdk/jdk/compare/master...xmas92:jdk:pre-init-expansion-rw-lock). Any potential performance gain may be better achieved by simply resolving the synchronisation issues with expansion._ 
> 
> * Testing
>   * GHA
>   * Tier 1-3 on Oracle supported platforms
>   * Stress-tested with reproducer `while java -XX:-UseCompressedOops -XX:+UseParallelGC -XX:InitialHeapSize=1m -Xmx1002M -version; do date;`

This pull request has now been integrated.

Changeset: f636fcad
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f636fcadd72eba7aefbf3f89777c14b3e3f19fb8
Stats:     16 lines in 1 file changed: 9 ins; 0 del; 7 mod

8372645: ParallelGC: Remove race between allocation and expansion before is_init_completed

Reviewed-by: ayang, sjohanss, eosterlund

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

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

From stefank at openjdk.org  Tue Dec  2 11:16:39 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Dec 2025 11:16:39 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
 <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
Message-ID: <_UMQvnKRYHj6G3yBFelY2isGYjdAmeEOJbQlOBcq33M=.40f433a0-ce8b-448e-9341-8a5adaf182c4@github.com>

On Tue, 2 Dec 2025 08:56:28 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> 
>> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> 2. `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
>> 3. Addition of ZGC to list of parallel collectors
>> 
>> Testing:
>> HS Tiers 1 and 2
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separating test sections

Nice! Thank you.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28566#pullrequestreview-3529551244

From duke at openjdk.org  Tue Dec  2 11:30:48 2025
From: duke at openjdk.org (duke)
Date: Tue, 2 Dec 2025 11:30:48 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
 <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
Message-ID: <l0oEM6jsh9_N3XsN_qvPwx81Ty-TBScj3rx-sKfgDq4=.893fe8c8-5a52-4d2b-93bf-ac32a41a458d@github.com>

On Tue, 2 Dec 2025 08:56:28 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> 
>> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> 2. `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
>> 3. Addition of ZGC to list of parallel collectors
>> 
>> Testing:
>> HS Tiers 1 and 2
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separating test sections

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28566#issuecomment-3601558681

From rsunderbabu at openjdk.org  Tue Dec  2 11:30:48 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 2 Dec 2025 11:30:48 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
 <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
Message-ID: <m_RpWDwvGvgmknNrKjcXnFm8rXruykPSXm7dnQjMxPs=.3a070479-7828-4c6e-a98c-9cda0a08ab12@github.com>

On Tue, 2 Dec 2025 08:56:28 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> 
>> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> 2. `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
>> 3. Addition of ZGC to list of parallel collectors
>> 
>> Testing:
>> HS Tiers 1 and 2
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separating test sections

Please sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/28566#issuecomment-3601561754

From jsikstro at openjdk.org  Tue Dec  2 11:58:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 2 Dec 2025 11:58:58 GMT
Subject: RFR: 8372747: G1: Conservative heap alignment does not account for
 card table constraint [v2]
In-Reply-To: <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
 <pICtUt-tZkIjgUhHOMQiQVpTg3cJ8JqjBA4secH2wbc=.86d2e12b-dba0-4040-89db-1494398b3ce8@github.com>
Message-ID: <PDYl9mUcKdCUkN9gJ5sD-yVHFZQMAwZh8HR1PVRJNY0=.42edf381-b325-4cef-9a09-1bac160c0f2f@github.com>

On Mon, 1 Dec 2025 10:16:24 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.
>> 
>> I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.
>> 
>>  uintx CardTable::ct_max_alignment_constraint() {
>>    // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
>> -  return GCCardSizeInBytes * os::vm_page_size();
>> +  return GCCardSizeInBytes * 64 * K;
>>  }
>> 
>> 
>> Also tested with Oracle's tier1-4.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify return a bit

Thank you for the reviews everyone!

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

PR Comment: https://git.openjdk.org/jdk/pull/28572#issuecomment-3601663052

From jsikstro at openjdk.org  Tue Dec  2 11:58:59 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 2 Dec 2025 11:58:59 GMT
Subject: Integrated: 8372747: G1: Conservative heap alignment does not account
 for card table constraint
In-Reply-To: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
References: <nXyM_OcDxVohxaBaLMYSgN2Yz_vplTOQEJGDoRvlMIw=.7f091c5f-8ad7-4071-83dd-de7172919be4@github.com>
Message-ID: <CM0PP5l42LYJSHKuMS_KVbBeSoLG6cY2Yn-pN2J0dRs=.f12c9bc9-5e67-4c9c-8b5d-169a345d702d@github.com>

On Mon, 1 Dec 2025 09:26:20 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> We removed `GCArguments::compute_heap_alignment` in [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150) to simplify the interface a bit, with the expecation that each GC handles alignment on their own. This is true when the default "small" page size is 4K, but with 64K default "small" pages on PPC, this assumption doesn't hold. To fix this, we should make sure to account for the card table constraints in `G1Arguments::conservative_max_heap_alignment`.
> 
> I've tested this locally by changing the following line to "emulate" 64K default "small" pages, which I've used to confirm this fix.
> 
>  uintx CardTable::ct_max_alignment_constraint() {
>    // Calculate maximum alignment using GCCardSizeInBytes as card_size hasn't been set yet
> -  return GCCardSizeInBytes * os::vm_page_size();
> +  return GCCardSizeInBytes * 64 * K;
>  }
> 
> 
> Also tested with Oracle's tier1-4.

This pull request has now been integrated.

Changeset: 3f046f6d
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f046f6dec72392d0693655c0f0ef9189529ce45
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8372747: G1: Conservative heap alignment does not account for card table constraint

Reviewed-by: mdoerr, stefank, tschatzl, sjohanss

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

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

From stefank at openjdk.org  Tue Dec  2 13:14:28 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Dec 2025 13:14:28 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
 <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
Message-ID: <MxqaT_41YJUaCWgRUkh-48HG9yp1p7Ez__EOqr6oUR4=.7cb96378-16e2-431c-845f-d0fb7edb88c0@github.com>

On Tue, 2 Dec 2025 08:56:28 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> 
>> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> 2. `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
>> 3. Addition of ZGC to list of parallel collectors
>> 
>> Testing:
>> HS Tiers 1 and 2
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separating test sections

Could you update the summary of this PR to reflect the final change? Could you also indicate that you have rerun the testing with the latest changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/28566#issuecomment-3601982344

From rsunderbabu at openjdk.org  Tue Dec  2 13:40:17 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 2 Dec 2025 13:40:17 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder
In-Reply-To: <oVT_CEkq9cKhEw_eBs8V1UIjg3B2bHf39RfZ022k4u0=.77c08d72-90f6-46f5-9ffd-725112f776a6@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
 <oVT_CEkq9cKhEw_eBs8V1UIjg3B2bHf39RfZ022k4u0=.77c08d72-90f6-46f5-9ffd-725112f776a6@github.com>
Message-ID: <tLQFmBqlNW87DhXp3CNPX4LDckoD7Q_vI5SiMPRHuZo=.48d10def-c876-43a7-b715-56782eac96c8@github.com>

On Wed, 26 Nov 2025 15:28:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Summary of change:
>> executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
>> 
>> Testing:
>> HS Tiers 1 and 2 
>> Ran with all flag combinations in CI
>
> Can you write a description in the PR why this change is correct? The test also supports Parallel GC, but there are requires lines for Serial and G1.

@stefank I have changed the requires condition since your comment and updated the PR description too. Please review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28508#issuecomment-3602116010

From kbarrett at openjdk.org  Tue Dec  2 13:54:22 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 2 Dec 2025 13:54:22 GMT
Subject: RFR: 8372564: Convert StringDedup to use Atomic<T>
In-Reply-To: <iOuGDyWZxhs11NwzIwazTM0UjDLAK1NkRZk75bgK7m4=.f9de3c91-1af9-42cd-8dba-5f6368260c5a@github.com>
References: <voobFETMOEBS-cmAzhAZTo5Gv2vAUARRELQAUyEF9Zk=.309cf890-2d32-4e0b-8f52-dc7f1610b314@github.com>
 <iOuGDyWZxhs11NwzIwazTM0UjDLAK1NkRZk75bgK7m4=.f9de3c91-1af9-42cd-8dba-5f6368260c5a@github.com>
Message-ID: <_pWUrDZNFKCxiG1getksYdzBTn4TM4UDiq5Hb3quOCY=.3fef7887-2b1c-4364-bd9e-2aa9fa7a3562@github.com>

On Tue, 2 Dec 2025 08:36:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Please review this change to StringDedup to use Atomic rather than directly
>> applying AtomicAccess to volatile members.
>> 
>> Testing: mach5 tier1-5
>
> src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.hpp line 56:
> 
>> 54: 
>> 55:   static OopStorage* _storages[2];
>> 56:   static DeferredStatic<Atomic<StorageUse*>> _storage_for_requests;
> 
> What is the reason for the `DeferredStatic`?
> 
> Is it just for the init once semantics and asserts?
> 
> _Is this a style we should adapt more broadly for our init once static variables?_

The Style Guide says

"Variables with static storage duration and _dynamic initialization_
[C++14 3.6.2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf)).
should be avoided, unless an implementation is permitted to perform the
initialization as a static initialization."

It may not be immediately obvious whether dynamic initialization is required.
(Currently, a non-local Atomic has dynamic initialization that is likely
reducible to static initialization when the ctor argument is a constant.
Making the Atomic ctors constexpr would make most such static. Translated
Atomics might also need the decay function to be constexpr.)

So the safe thing to do in this respect is to use DeferredStatic for a
non-local variable of class type. Of course, then you need to find a good
place to put the initialization. That already existed in the case at hand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28524#discussion_r2581291100

From stefank at openjdk.org  Tue Dec  2 14:09:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Dec 2025 14:09:21 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <IUfN20CkPlSwyTdMJq8oQA3JsYb9oGUfp6LUHk3zGEc=.4dc5d479-ca46-4346-9537-ed610ce2082a@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
 <IUfN20CkPlSwyTdMJq8oQA3JsYb9oGUfp6LUHk3zGEc=.4dc5d479-ca46-4346-9537-ed610ce2082a@github.com>
Message-ID: <3_kTrwNhqFkbNVLFgavCHgaEzy5b67075oAuIm1EmgI=.52edba07-4fb9-4a92-af1a-9e490eef2179@github.com>

On Sat, 29 Nov 2025 08:28:29 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
>> 
>> Testing:
>> HS Tiers 1 and 2 
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing the requires condition

I would prefer if we did a fix similar to the one you did in #28508.

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

PR Comment: https://git.openjdk.org/jdk/pull/28508#issuecomment-3602245243

From eosterlund at openjdk.org  Tue Dec  2 14:15:19 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 2 Dec 2025 14:15:19 GMT
Subject: RFR: 8372738: ZGC: C2 allocation reloc promotion deopt race [v2]
In-Reply-To: <_II-BLtqOWNsgXJn-xs0SXfRGkflp0JfOISA6CZowXE=.ec9fe0f6-ff71-40f0-8223-7283e17afb47@github.com>
References: <_II-BLtqOWNsgXJn-xs0SXfRGkflp0JfOISA6CZowXE=.ec9fe0f6-ff71-40f0-8223-7283e17afb47@github.com>
Message-ID: <z0TttzVfjSBuyrvuSUgz6BjaQEG9Pf-BCGlTBec2Rsk=.c59e5a8c-0ff6-47db-89db-2568fef52f8f@github.com>

> In https://bugs.openjdk.org/browse/JDK-8371200 a race was handled between flip promoting objects, their promotion barriers, tenuring threshold selection and signalling to the JIT slow path allocation code to deoptimize. It made sure that flip promoted objects are made old before a handshake with the Java threads, and ran promotion barriers to erase any raw nulls after the handshake. This order was crucial to the fix.
> 
> Now unfortunately, there is a related problem for relocate promoting objects. Such objects run the promotion barriers before the object becomes old, which is the signal for the JIT allocation slow path code to deopt. Unfortunately, the order should be the opposite, similar to flip promoted objects. I propose signalling that relocate promoting pages are marked as relocate promoted during relocation set selection, and include that as a condition for deopt in the allocation slow path. The relocation set selection runs before the handshake, hence ensuring that promotion barriers won't race with JIT compiled code that has elided barriers.
> 
> T1-5 tests look good. The test that failed before reproduces an observable issue without the fix and not after the fix.

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  StefanK comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28558/files
  - new: https://git.openjdk.org/jdk/pull/28558/files/e0bf6f4e..5cabcf6f

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

  Stats: 29 lines in 5 files changed: 12 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28558.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28558/head:pull/28558

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

From stefank at openjdk.org  Tue Dec  2 14:22:01 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Dec 2025 14:22:01 GMT
Subject: RFR: 8372738: ZGC: C2 allocation reloc promotion deopt race [v2]
In-Reply-To: <z0TttzVfjSBuyrvuSUgz6BjaQEG9Pf-BCGlTBec2Rsk=.c59e5a8c-0ff6-47db-89db-2568fef52f8f@github.com>
References: <_II-BLtqOWNsgXJn-xs0SXfRGkflp0JfOISA6CZowXE=.ec9fe0f6-ff71-40f0-8223-7283e17afb47@github.com>
 <z0TttzVfjSBuyrvuSUgz6BjaQEG9Pf-BCGlTBec2Rsk=.c59e5a8c-0ff6-47db-89db-2568fef52f8f@github.com>
Message-ID: <-jVYUbWsVPh3PlWVF687TFBCFujW4vkT6EaxbAkByZM=.812251e1-3e9d-42b2-97f6-8048550d1ad1@github.com>

On Tue, 2 Dec 2025 14:15:19 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> In https://bugs.openjdk.org/browse/JDK-8371200 a race was handled between flip promoting objects, their promotion barriers, tenuring threshold selection and signalling to the JIT slow path allocation code to deoptimize. It made sure that flip promoted objects are made old before a handshake with the Java threads, and ran promotion barriers to erase any raw nulls after the handshake. This order was crucial to the fix.
>> 
>> Now unfortunately, there is a related problem for relocate promoting objects. Such objects run the promotion barriers before the object becomes old, which is the signal for the JIT allocation slow path code to deopt. Unfortunately, the order should be the opposite, similar to flip promoted objects. I propose signalling that relocate promoting pages are marked as relocate promoted during relocation set selection, and include that as a condition for deopt in the allocation slow path. The relocation set selection runs before the handshake, hence ensuring that promotion barriers won't race with JIT compiled code that has elided barriers.
>> 
>> T1-5 tests look good. The test that failed before reproduces an observable issue without the fix and not after the fix.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   StefanK comments

Looks good!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28558#pullrequestreview-3530384712

From aboldtch at openjdk.org  Tue Dec  2 14:32:16 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 2 Dec 2025 14:32:16 GMT
Subject: RFR: 8372738: ZGC: C2 allocation reloc promotion deopt race [v2]
In-Reply-To: <z0TttzVfjSBuyrvuSUgz6BjaQEG9Pf-BCGlTBec2Rsk=.c59e5a8c-0ff6-47db-89db-2568fef52f8f@github.com>
References: <_II-BLtqOWNsgXJn-xs0SXfRGkflp0JfOISA6CZowXE=.ec9fe0f6-ff71-40f0-8223-7283e17afb47@github.com>
 <z0TttzVfjSBuyrvuSUgz6BjaQEG9Pf-BCGlTBec2Rsk=.c59e5a8c-0ff6-47db-89db-2568fef52f8f@github.com>
Message-ID: <oU1CT54oXHYfzZreMNxQ_BBwx9x3NsB_zUItyodpNYY=.03ee8815-5d62-456e-a2b4-ef85b534bfc6@github.com>

On Tue, 2 Dec 2025 14:15:19 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> In https://bugs.openjdk.org/browse/JDK-8371200 a race was handled between flip promoting objects, their promotion barriers, tenuring threshold selection and signalling to the JIT slow path allocation code to deoptimize. It made sure that flip promoted objects are made old before a handshake with the Java threads, and ran promotion barriers to erase any raw nulls after the handshake. This order was crucial to the fix.
>> 
>> Now unfortunately, there is a related problem for relocate promoting objects. Such objects run the promotion barriers before the object becomes old, which is the signal for the JIT allocation slow path code to deopt. Unfortunately, the order should be the opposite, similar to flip promoted objects. I propose signalling that relocate promoting pages are marked as relocate promoted during relocation set selection, and include that as a condition for deopt in the allocation slow path. The relocation set selection runs before the handshake, hence ensuring that promotion barriers won't race with JIT compiled code that has elided barriers.
>> 
>> T1-5 tests look good. The test that failed before reproduces an observable issue without the fix and not after the fix.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   StefanK comments

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28558#pullrequestreview-3530435425

From rsunderbabu at openjdk.org  Tue Dec  2 14:37:20 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 2 Dec 2025 14:37:20 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <MxqaT_41YJUaCWgRUkh-48HG9yp1p7Ez__EOqr6oUR4=.7cb96378-16e2-431c-845f-d0fb7edb88c0@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
 <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
 <MxqaT_41YJUaCWgRUkh-48HG9yp1p7Ez__EOqr6oUR4=.7cb96378-16e2-431c-845f-d0fb7edb88c0@github.com>
Message-ID: <a2r-Ff6QFFsTUQF1VWldfJqpkyu7EGTob08Z4oLGf4Y=.e1343ca8-b72a-4ff3-aebe-e8d79302b88c@github.com>

On Tue, 2 Dec 2025 13:12:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Could you update the summary of this PR to reflect the final change? Could you also indicate that you have rerun the testing with the latest changes?

The following testing have been done after the latest changes.
HS Tiers 1 and 2
Ran with all flag combinations in CI

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

PR Comment: https://git.openjdk.org/jdk/pull/28566#issuecomment-3602366878

From rsunderbabu at openjdk.org  Tue Dec  2 15:25:06 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 2 Dec 2025 15:25:06 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <3_kTrwNhqFkbNVLFgavCHgaEzy5b67075oAuIm1EmgI=.52edba07-4fb9-4a92-af1a-9e490eef2179@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
 <IUfN20CkPlSwyTdMJq8oQA3JsYb9oGUfp6LUHk3zGEc=.4dc5d479-ca46-4346-9537-ed610ce2082a@github.com>
 <3_kTrwNhqFkbNVLFgavCHgaEzy5b67075oAuIm1EmgI=.52edba07-4fb9-4a92-af1a-9e490eef2179@github.com>
Message-ID: <noM9ZvzwwLbu_Hafby4scgsNE7StUpSt8oMOSvNyo1s=.c23b63ff-b78e-43bc-b701-d66b52bbf186@github.com>

On Tue, 2 Dec 2025 14:06:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I would prefer if we did a fix similar to the one you did in #28508.

I guess you mean #28566. I will restructure this test along those lines.
Although #28422 is already closed, shall I rework TestSelectDefaultGC also?

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

PR Comment: https://git.openjdk.org/jdk/pull/28508#issuecomment-3602586022

From kbarrett at openjdk.org  Tue Dec  2 15:48:00 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 2 Dec 2025 15:48:00 GMT
Subject: RFR: 8372564: Convert StringDedup to use Atomic<T>
In-Reply-To: <_pWUrDZNFKCxiG1getksYdzBTn4TM4UDiq5Hb3quOCY=.3fef7887-2b1c-4364-bd9e-2aa9fa7a3562@github.com>
References: <voobFETMOEBS-cmAzhAZTo5Gv2vAUARRELQAUyEF9Zk=.309cf890-2d32-4e0b-8f52-dc7f1610b314@github.com>
 <iOuGDyWZxhs11NwzIwazTM0UjDLAK1NkRZk75bgK7m4=.f9de3c91-1af9-42cd-8dba-5f6368260c5a@github.com>
 <_pWUrDZNFKCxiG1getksYdzBTn4TM4UDiq5Hb3quOCY=.3fef7887-2b1c-4364-bd9e-2aa9fa7a3562@github.com>
Message-ID: <rUOvkZX1AMkRiaIz7lDIpnuEI83ziE7WZJmWpx8jZRg=.6239ffc8-fd91-4809-b152-71b48bfeca4f@github.com>

On Tue, 2 Dec 2025 13:51:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.hpp line 56:
>> 
>>> 54: 
>>> 55:   static OopStorage* _storages[2];
>>> 56:   static DeferredStatic<Atomic<StorageUse*>> _storage_for_requests;
>> 
>> What is the reason for the `DeferredStatic`?
>> 
>> Is it just for the init once semantics and asserts?
>> 
>> _Is this a style we should adapt more broadly for our init once static variables?_
>
> The Style Guide says
> 
> "Variables with static storage duration and _dynamic initialization_
> [C++14 3.6.2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf)).
> should be avoided, unless an implementation is permitted to perform the
> initialization as a static initialization."
> 
> It may not be immediately obvious whether dynamic initialization is required.
> (Currently, a non-local Atomic has dynamic initialization that is likely
> reducible to static initialization when the ctor argument is a constant.
> Making the Atomic ctors constexpr would make most such static. Translated
> Atomics might also need the decay function to be constexpr.)
> 
> So the safe thing to do in this respect is to use DeferredStatic for a
> non-local variable of class type. Of course, then you need to find a good
> place to put the initialization. That already existed in the case at hand.

We discussed this a bit more, and decided to make the Atomic ctors constexpr
so that, with constant arguments, they are guaranteed to be static initialized.
And then change this to remove the use of DeferredStatic and instead have the
uses assert non-null the way they used to, instead of using the DeferredStatic
initialization check. The benefit is that many uses of non-local Atomic
definitely don't need the additional DeferredStatic ceremony.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28524#discussion_r2581765344

From stefank at openjdk.org  Tue Dec  2 15:47:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Dec 2025 15:47:52 GMT
Subject: RFR: 8319158: Parallel: Make TestObjectTenuringFlags use
 createTestJavaProcessBuilder
In-Reply-To: <5HbSzSNnNDiViXu6CzD_KsLbB4dpnC4VQjVpjDHqLm0=.4bce9f53-e4f1-44e2-95e5-ffa1a45be57d@github.com>
References: <5HbSzSNnNDiViXu6CzD_KsLbB4dpnC4VQjVpjDHqLm0=.4bce9f53-e4f1-44e2-95e5-ffa1a45be57d@github.com>
Message-ID: <nXrCpnOwHR4wn1pAHn_6UB-DT4LnyCYwqbWBB8dWqfc=.f0a2e44c-fb64-4653-b1eb-ebb6ef59394c@github.com>

On Sat, 29 Nov 2025 18:22:42 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Summary of change:
> 
> executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
> @requires condition is expanded to include flags used in the test so that external flag settings don't disturb them.
> 
> Testing:
> HS Tiers 1 and 2
> Ran with all flag combinations in CI

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28567#pullrequestreview-3530842427

From duke at openjdk.org  Tue Dec  2 15:52:54 2025
From: duke at openjdk.org (duke)
Date: Tue, 2 Dec 2025 15:52:54 GMT
Subject: RFR: 8319158: Parallel: Make TestObjectTenuringFlags use
 createTestJavaProcessBuilder
In-Reply-To: <5HbSzSNnNDiViXu6CzD_KsLbB4dpnC4VQjVpjDHqLm0=.4bce9f53-e4f1-44e2-95e5-ffa1a45be57d@github.com>
References: <5HbSzSNnNDiViXu6CzD_KsLbB4dpnC4VQjVpjDHqLm0=.4bce9f53-e4f1-44e2-95e5-ffa1a45be57d@github.com>
Message-ID: <ekcE2h22n-kNBHz4-jMdZhOTrSe7f8ioXfNprSvfE7I=.d1c1500e-9a65-433c-9ef0-4676305a6332@github.com>

On Sat, 29 Nov 2025 18:22:42 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Summary of change:
> 
> executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
> @requires condition is expanded to include flags used in the test so that external flag settings don't disturb them.
> 
> Testing:
> HS Tiers 1 and 2
> Ran with all flag combinations in CI

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28567#issuecomment-3602725213

From wkemper at openjdk.org  Tue Dec  2 18:29:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Dec 2025 18:29:21 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v10]
In-Reply-To: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
Message-ID: <LuGtPK_bNwOXS7zrQVxkgV-rhtfgj26TQXqO3dqUI4s=.095cb614-53bd-4f04-8dee-d4b4e2489950@github.com>

> Notable changes:
> * Improvements to logging
> * More accurate tracking of promotion failures
> * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size)
> * Use census information gathered during mark to size promotion reserves and old generation
> 
> With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results.
> 
> Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks:
> 
> 
> Concurrent Evacuation: 7 improvements, 3 regressions
> ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%)
> ? Worst regression: xalan (+53.7%)
> 
> Concurrent Marking: 15 improvements, 1 regression  
> ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%)
> ? Only regression: serial (+8.9%)
> 
> Concurrent Scan Remembered Set: 7 improvements, 2 regressions
> ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%)
> ? Worst regression: extremem-phased (+52.4%)
> 
> Concurrent Update Refs: 5 improvements, 4 regressions
> ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%)
> ? Worst regression: xalan (+89.4%)

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

 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Adaptive tenuring is no longer optional
   
   We are using age census data to compute promotion reserves. The tenuring threshold may still be fixed by setting the min/max threshold to the same value.
 - Remove bad asserts
 - Don't include tenurable bytes for current cycle in the next cycle
   
   Also remove vestigial promotion potential calculation
 - Idle fix ups
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Disable assertion (will revisit later)
 - Print global evac tracking after other gc stats
   
   This makes it easier for parsers to distinguish from per cycle reports
 - Instrumentation and assertions
 - Idle cleanup as I read
 - ... and 63 more: https://git.openjdk.org/jdk/compare/5627ff2d...0c682e1c

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

Changes: https://git.openjdk.org/jdk/pull/27632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=09
  Stats: 406 lines in 11 files changed: 166 ins; 182 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/27632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27632/head:pull/27632

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

From xpeng at openjdk.org  Tue Dec  2 18:40:16 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 2 Dec 2025 18:40:16 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code:
> 
> * ShenandoahAllocator: base class the allocator, most of the allocation code is in the class.
> * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and  `_yield_to_safepoint` to customize the allocator for mutator.
> * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. 
> * ShenandoahOldCollectorAllocator:  allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector`
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. 
> 
> java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> 
> 
> Openjdk TIP:
> 
> ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 2608 u...

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 255 commits:

 - Add missing header for ShenandoahFreeSetPartitionId
 - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
 - Fix a typo
 - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
 - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
 - Port the fix of JDK-8372566
 - Merge branch 'master' into cas-alloc-1
 - Merge remote-tracking branch 'origin/master' into cas-alloc-1
 - Remove junk code
 - Remove unnecessary change and tidy up
 - ... and 245 more: https://git.openjdk.org/jdk/compare/79e99bb0...7980c039

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

Changes: https://git.openjdk.org/jdk/pull/26171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=13
  Stats: 1637 lines in 25 files changed: 1283 ins; 242 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

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

From xpeng at openjdk.org  Tue Dec  2 18:40:21 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 2 Dec 2025 18:40:21 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v5]
In-Reply-To: <VwCu14Y6D5yalCWr-Q-oUOJ5SROVlrHRYXkXXzKCiDs=.d99b38f5-6618-4564-89c6-6f9604c0f8c3@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <JAyYP5BmPJpXWfdQt3NTPUC8KQQ5F-rRc-b2AFfrjTs=.42295acf-daa5-4d7b-ac05-323416e88163@github.com>
 <VwCu14Y6D5yalCWr-Q-oUOJ5SROVlrHRYXkXXzKCiDs=.d99b38f5-6618-4564-89c6-6f9604c0f8c3@github.com>
Message-ID: <IKz9BV7KfEqu7KwS_Io4p7lJX6Fcw4iR0y_d1km_wy8=.6bd7becf-1ecc-4aba-9057-227921070e36@github.com>

On Wed, 5 Nov 2025 20:31:18 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 pull request now contains 135 commits:
>> 
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - format
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - Merge branch 'master' into cas-alloc-1
>>  - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - Fix errors caused by renaming ofAtomic to AtomicAccess
>>  - Merge branch 'openjdk:master' into cas-alloc-1
>>  - ... and 125 more: https://git.openjdk.org/jdk/compare/2f613911...e6bfef05
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 271:
> 
>> 269:     _used[int(which_partition)] = value;
>> 270:     _available[int(which_partition)] = _capacity[int(which_partition)] - value;
>> 271:     AtomicAccess::store(_used + int(which_partition), value);
> 
> Also here, should not require AtomicAccess.

Sorry, it is junk code left over, I'm tidying up the changes in the PR, this line will be removed.

> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 363:
> 
>> 361: }
>> 362: 
>> 363: void ShenandoahHeapRegion::reset_alloc_metadata() {
> 
> Do we need to make these atomic because we now increment asynchronously from within mutator CAS allocations?  Before, they were only adjusted while holding heap lock?  I'm wondering if add-with-fetch() or CAS() would be more/less efficient than AtomicAccess::stores.  Can we test the tradeoffs?

Yes, we need to update these from mutator after every allocation w/o heap lock.

`reset_alloc_metadata` it to reset the values, we have to use AtomicAccess::store, it is not in the hot path, it is only invoked when the region is recycled, I don't think there is performance issue here.

For the code in hot path of mem allocation, I simply use `AtomicAccess::add` with `memory_order_relaxed`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2562099016
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2562086131

From xpeng at openjdk.org  Tue Dec  2 19:07:35 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 2 Dec 2025 19:07:35 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism
Message-ID: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>

In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 

In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.

Test result:

java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"

With the change:

[77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
[77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)

Original:


[77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
[77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)


The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 100%+ improvement.

### Other tests
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - Fix wrong impl of parallel_region_stride in ShenandoahExcludeRegionClosure & ShenandoahIncludeRegionClosure
 - Add comments
 - Set parallel_region_stride to 8 for ShenandoahResetBitmapClosure
 - Tidying
 - Override ShenandoahParallelRegionStride to 8 when wrap the closure with ShenandoahIncludeRegionClosure
 - Override ShenandoahParallelRegionStride to 8 when wrap the closure with ShenandoahExcludeRegionClosure

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

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

From wkemper at openjdk.org  Tue Dec  2 19:31:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Dec 2025 19:31:25 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v11]
In-Reply-To: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
Message-ID: <AI-1RHEcxqjzv08mlP6MuvDEsUCtWDLhLQ1AJEIfvXU=.695bdaa7-d939-48db-9537-aba6c929619d@github.com>

> Notable changes:
> * Improvements to logging
> * More accurate tracking of promotion failures
> * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size)
> * Use census information gathered during mark to size promotion reserves and old generation
> 
> With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results.
> 
> Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks:
> 
> 
> Concurrent Evacuation: 7 improvements, 3 regressions
> ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%)
> ? Worst regression: xalan (+53.7%)
> 
> Concurrent Marking: 15 improvements, 1 regression  
> ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%)
> ? Only regression: serial (+8.9%)
> 
> Concurrent Scan Remembered Set: 7 improvements, 2 regressions
> ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%)
> ? Worst regression: extremem-phased (+52.4%)
> 
> Concurrent Update Refs: 5 improvements, 4 regressions
> ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%)
> ? Worst regression: xalan (+89.4%)

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

  Remove commented out assertion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27632/files
  - new: https://git.openjdk.org/jdk/pull/27632/files/0c682e1c..502797a6

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

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

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

From kdnilsen at openjdk.org  Tue Dec  2 19:31:45 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 2 Dec 2025 19:31:45 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism
In-Reply-To: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
Message-ID: <LFcz2aBc_mjTVP2y6GLt5Bz8UX4Vsq4CO0U6H_DLiy4=.edcbce96-33a7-4e1f-9d5e-e0670982798e@github.com>

On Tue, 2 Dec 2025 18:59:25 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
> 
> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
> 
> Test result:
> 
> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
> 
> With the change:
> 
> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
> 
> Original:
> 
> 
> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
> 
> 
> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 100%+ improvement.
> 
> ### Other tests
> - [x] hotspot_gc_shenandoah

I think this is a 58% improvement (in the header) rather than a 100% improvement.

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

PR Comment: https://git.openjdk.org/jdk/pull/28613#issuecomment-3603643649

From kdnilsen at openjdk.org  Tue Dec  2 19:43:04 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 2 Dec 2025 19:43:04 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism
In-Reply-To: <Li9mpQOvPyHQRrQo1RtNRE2KH0KTbjkL0N6uN-y2YcA=.736a6b43-f18d-4dc9-9e51-a893d4638573@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <Li9mpQOvPyHQRrQo1RtNRE2KH0KTbjkL0N6uN-y2YcA=.736a6b43-f18d-4dc9-9e51-a893d4638573@github.com>
Message-ID: <8YLFumpKphkiO-9PU9GbDz8g5XA388yLqD9xzlm9LUg=.ed2f7155-a371-4eeb-90bf-2bc45f63e900@github.com>

On Tue, 2 Dec 2025 19:33:01 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
>> 
>> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
>> 
>> Test result:
>> 
>> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
>> 
>> With the change:
>> 
>> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
>> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
>> 
>> Original:
>> 
>> 
>> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
>> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
>> 
>> 
>> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 100%+ improvement.
>> 
>> ### Other tests
>> - [x] hotspot_gc_shenandoah
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 83:
> 
>> 81:   // For a 31G heap resetting bitmaps could take more than 60ms for single thread, we should use a small
>> 82:   // parallel region stride for ShenandoahResetBitmapClosure.
>> 83:   size_t parallel_region_stride() override { return 8; }
> 
> Should this be:
> 
> if (ShenandoahParallelRegionStride == 0) {
>   return 8;
> } else {
>   return ShenandoahParallelRegionStride;
> }

In fact, rather than the "constant" value 8, should we return ShenandoahWorkerPolicy::calc_workers_for_conc_reset()?

This makes the change robust against future integration of "worker surge".

In fact, the parallel stride depends on the reason we are iterating.  Can we make this change more "generic"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2582566703

From kdnilsen at openjdk.org  Tue Dec  2 19:43:03 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 2 Dec 2025 19:43:03 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism
In-Reply-To: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
Message-ID: <Li9mpQOvPyHQRrQo1RtNRE2KH0KTbjkL0N6uN-y2YcA=.736a6b43-f18d-4dc9-9e51-a893d4638573@github.com>

On Tue, 2 Dec 2025 18:59:25 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
> 
> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
> 
> Test result:
> 
> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
> 
> With the change:
> 
> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
> 
> Original:
> 
> 
> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
> 
> 
> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 100%+ improvement.
> 
> ### Other tests
> - [x] hotspot_gc_shenandoah

See below

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

> 81:   // For a 31G heap resetting bitmaps could take more than 60ms for single thread, we should use a small
> 82:   // parallel region stride for ShenandoahResetBitmapClosure.
> 83:   size_t parallel_region_stride() override { return 8; }

Should this be:

if (ShenandoahParallelRegionStride == 0) {
  return 8;
} else {
  return ShenandoahParallelRegionStride;
}

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

Changes requested by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28613#pullrequestreview-3531815307
PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2582551300

From xpeng at openjdk.org  Tue Dec  2 20:02:16 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 2 Dec 2025 20:02:16 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism
In-Reply-To: <LFcz2aBc_mjTVP2y6GLt5Bz8UX4Vsq4CO0U6H_DLiy4=.edcbce96-33a7-4e1f-9d5e-e0670982798e@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <LFcz2aBc_mjTVP2y6GLt5Bz8UX4Vsq4CO0U6H_DLiy4=.edcbce96-33a7-4e1f-9d5e-e0670982798e@github.com>
Message-ID: <lk2go_0uUpa97NyfV_bI2uYF4IO1-4MFkNOTJrqx_GI=.9f82eadc-246c-4e92-929d-3efee775f9d2@github.com>

On Tue, 2 Dec 2025 19:28:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> I think this is a 58% improvement (in the header) rather than a 100% improvement.

To be precise, it is  58% time reduction, 100+% speed/throughput improvement, I have updated the description.

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

PR Comment: https://git.openjdk.org/jdk/pull/28613#issuecomment-3603737834

From xpeng at openjdk.org  Tue Dec  2 22:03:25 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 2 Dec 2025 22:03:25 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism
In-Reply-To: <8YLFumpKphkiO-9PU9GbDz8g5XA388yLqD9xzlm9LUg=.ed2f7155-a371-4eeb-90bf-2bc45f63e900@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <Li9mpQOvPyHQRrQo1RtNRE2KH0KTbjkL0N6uN-y2YcA=.736a6b43-f18d-4dc9-9e51-a893d4638573@github.com>
 <8YLFumpKphkiO-9PU9GbDz8g5XA388yLqD9xzlm9LUg=.ed2f7155-a371-4eeb-90bf-2bc45f63e900@github.com>
Message-ID: <3MGUEGMsFxAnh_r0WE8hRt9FpH3ey0_xgKz_K3jaruQ=.4167d995-ba80-405f-bd17-9b77168d26ad@github.com>

On Tue, 2 Dec 2025 19:40:19 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 83:
>> 
>>> 81:   // For a 31G heap resetting bitmaps could take more than 60ms for single thread, we should use a small
>>> 82:   // parallel region stride for ShenandoahResetBitmapClosure.
>>> 83:   size_t parallel_region_stride() override { return 8; }
>> 
>> Should this be:
>> 
>> if (ShenandoahParallelRegionStride == 0) {
>>   return 8;
>> } else {
>>   return ShenandoahParallelRegionStride;
>> }
>
> In fact, rather than the "constant" value 8, should we return ShenandoahWorkerPolicy::calc_workers_for_conc_reset()?
> 
> This makes the change robust against future integration of "worker surge".
> 
> In fact, the parallel stride depends on the reason we are iterating.  Can we make this change more "generic"?

The intention of the change is to let `ShenandoahResetBitmapClosure` not use the ShenandoahParallelRegionStride global value at all, here is the reasons: 
ShenandoahParallelRegionStride is usually set to a large value, the default value used to be 1024, large value won't help with the performance ShenandoahHeapRegionClosure at all for some reasons:
1. ShenandoahResetBitmapClosure reset the marking bitmaps before/after GC cycle, the resetting may not not needed for each region. e.g. when `top_bitmap == bottom`(immediate trash regions?) or the region is not current gc generation.
2. Withe large ShenandoahParallelRegionStride, each task will get large number of successive regions, e.g. worker 0 will process region 1 to region 1024, in this way it is not possible to make sure the actual workload is evenly distributed to all workers, some of the workers may have most of the regions need bitmap reset, some of the worker may not really do any actual bitmap reset at all. 

A smaller parallel region stride value will help with the workload distribution and also make it adaptive to different number of workers, it should be also working just fine with "worker surge"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2582857990

From xpeng at openjdk.org  Tue Dec  2 22:03:28 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 2 Dec 2025 22:03:28 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism
In-Reply-To: <3MGUEGMsFxAnh_r0WE8hRt9FpH3ey0_xgKz_K3jaruQ=.4167d995-ba80-405f-bd17-9b77168d26ad@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <Li9mpQOvPyHQRrQo1RtNRE2KH0KTbjkL0N6uN-y2YcA=.736a6b43-f18d-4dc9-9e51-a893d4638573@github.com>
 <8YLFumpKphkiO-9PU9GbDz8g5XA388yLqD9xzlm9LUg=.ed2f7155-a371-4eeb-90bf-2bc45f63e900@github.com>
 <3MGUEGMsFxAnh_r0WE8hRt9FpH3ey0_xgKz_K3jaruQ=.4167d995-ba80-405f-bd17-9b77168d26ad@github.com>
Message-ID: <6TAyVPTOcp6ykpzuzVuTP04UU8mk0tSkakJEinh4dnA=.4c43b199-09b5-4b9c-984d-c69cdca0b294@github.com>

On Tue, 2 Dec 2025 21:38:26 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In fact, rather than the "constant" value 8, should we return ShenandoahWorkerPolicy::calc_workers_for_conc_reset()?
>> 
>> This makes the change robust against future integration of "worker surge".
>> 
>> In fact, the parallel stride depends on the reason we are iterating.  Can we make this change more "generic"?
>
> The intention of the change is to let `ShenandoahResetBitmapClosure` not use the ShenandoahParallelRegionStride global value at all, here is the reasons: 
> ShenandoahParallelRegionStride is usually set to a large value, the default value used to be 1024, large value won't help with the performance ShenandoahHeapRegionClosure at all for some reasons:
> 1. ShenandoahResetBitmapClosure reset the marking bitmaps before/after GC cycle, the resetting may not not needed for each region. e.g. when `top_bitmap == bottom`(immediate trash regions?) or the region is not current gc generation.
> 2. Withe large ShenandoahParallelRegionStride, each task will get large number of successive regions, e.g. worker 0 will process region 1 to region 1024, in this way it is not possible to make sure the actual workload is evenly distributed to all workers, some of the workers may have most of the regions need bitmap reset, some of the worker may not really do any actual bitmap reset at all. 
> 
> A smaller parallel region stride value will help with the workload distribution and also make it adaptive to different number of workers, it should be also working just fine with "worker surge"

In the JBS bug report, I attached a test I did for this, I have tested value from 1 to 4096:

java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -XX:ShenandoahParallelRegionStride=<Stride Value>-jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"



[1]
[77.444s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3078 us) (n = 14) (lvls, us = 1172, 1289, 1328, 1406, 14780)
[77.444s][info][gc,stats ] Concurrent Reset After Collect = 0.044 s (a = 3150 us) (n = 14) (lvls, us = 1074, 1504, 1895, 4121, 8952)

[2]
[77.304s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3036 us) (n = 14) (lvls, us = 1152, 1211, 1289, 1328, 14872)
[77.305s][info][gc,stats ] Concurrent Reset After Collect = 0.046 s (a = 3297 us) (n = 14) (lvls, us = 939, 1602, 2148, 3945, 8744)


[4]
[76.898s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3048 us) (n = 14) (lvls, us = 1152, 1230, 1270, 1328, 14989)
[76.898s][info][gc,stats ] Concurrent Reset After Collect = 0.045 s (a = 3215 us) (n = 14) (lvls, us = 1016, 1309, 1914, 3301, 7076)

[8]
[77.916s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3067 us) (n = 14) (lvls, us = 1152, 1211, 1270, 1309, 15091)
[77.916s][info][gc,stats ] Concurrent Reset After Collect = 0.043 s (a = 3050 us) (n = 14) (lvls, us = 1133, 1484, 1934, 3086, 8113)

[16]
[77.071s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3019 us) (n = 14) (lvls, us = 1152, 1250, 1270, 1328, 14615)
[77.071s][info][gc,stats ] Concurrent Reset After Collect = 0.046 s (a = 3284 us) (n = 14) (lvls, us = 932, 1523, 2090, 2930, 8841)

[32]
[76.965s][info][gc,stats ] Concurrent Reset = 0.044 s (a = 3117 us) (n = 14) (lvls, us = 1191, 1211, 1328, 1348, 14768)
[76.965s][info][gc,stats ] Concurrent Reset After Collect = 0.047 s (a = 3323 us) (n = 14) (lvls, us = 930, 1406, 1875, 4316, 8565)


[64]
[77.255s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3033 us) (n = 14) (lvls, us = 1152, 1211, 1270, 1406, 14635)
[77.255s][info][gc,stats ] Concurrent Reset After Collect = 0.054 s (a = 3862 us) (n = 14) (lvls, us = 1133, 1504, 2852, 5508, 8947)

[128]
[76.502s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3027 us) (n = 14) (lvls, us = 1133, 1230, 1250, 1426, 14264)
[76.502s][info][gc,stats ] Concurrent Reset After Collect = 0.053 s (a = 3762 us) (n = 14) (lvls, us = 1172, 1582, 2129, 5273, 9272)

[256]
[76.751s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3057 us) (n = 14) (lvls, us = 1133, 1230, 1270, 1426, 14713)
[76.751s][info][gc,stats ] Concurrent Reset After Collect = 0.056 s (a = 4029 us) (n = 14) (lvls, us = 1484, 1602, 3027, 4629, 11267)

[512]
[77.508s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3082 us) (n = 14) (lvls, us = 1133, 1230, 1270, 1426, 14893)
[77.508s][info][gc,stats ] Concurrent Reset After Collect = 0.068 s (a = 4822 us) (n = 14) (lvls, us = 1953, 2285, 3633, 5605, 16366)

[1024]
[76.933s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3073 us) (n = 14) (lvls, us = 1152, 1211, 1270, 1426, 14957)
[76.933s][info][gc,stats ] Concurrent Reset After Collect = 0.082 s (a = 5877 us) (n = 14) (lvls, us = 1895, 3203, 4258, 7793, 15587)

[2048]
[76.746s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3022 us) (n = 14) (lvls, us = 1133, 1172, 1211, 1406, 14586)
[76.746s][info][gc,stats ] Concurrent Reset After Collect = 0.099 s (a = 7104 us) (n = 14) (lvls, us = 1875, 3281, 4590, 7695, 19292)

[4096]
[77.356s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3031 us) (n = 14) (lvls, us = 1133, 1191, 1250, 1426, 14606)
[77.356s][info][gc,stats ] Concurrent Reset After Collect = 0.101 s (a = 7213 us) (n = 14) (lvls, us = 1914, 3262, 4238, 7871, 19862)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2582863336

From wkemper at openjdk.org  Tue Dec  2 22:15:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Dec 2025 22:15:36 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism
In-Reply-To: <6TAyVPTOcp6ykpzuzVuTP04UU8mk0tSkakJEinh4dnA=.4c43b199-09b5-4b9c-984d-c69cdca0b294@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <Li9mpQOvPyHQRrQo1RtNRE2KH0KTbjkL0N6uN-y2YcA=.736a6b43-f18d-4dc9-9e51-a893d4638573@github.com>
 <8YLFumpKphkiO-9PU9GbDz8g5XA388yLqD9xzlm9LUg=.ed2f7155-a371-4eeb-90bf-2bc45f63e900@github.com>
 <3MGUEGMsFxAnh_r0WE8hRt9FpH3ey0_xgKz_K3jaruQ=.4167d995-ba80-405f-bd17-9b77168d26ad@github.com>
 <6TAyVPTOcp6ykpzuzVuTP04UU8mk0tSkakJEinh4dnA=.4c43b199-09b5-4b9c-984d-c69cdca0b294@github.com>
Message-ID: <ELKo3crueRABaquE-xWwOs_p-fQYUPGWL1HMU0ZfYAs=.4a0260df-72d7-445d-83be-e5acbe8b47da@github.com>

On Tue, 2 Dec 2025 21:40:29 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> The intention of the change is to let `ShenandoahResetBitmapClosure` not use the ShenandoahParallelRegionStride global value at all, here is the reasons: 
>> ShenandoahParallelRegionStride is usually set to a large value, the default value used to be 1024, large value won't help with the performance ShenandoahHeapRegionClosure at all for some reasons:
>> 1. ShenandoahResetBitmapClosure reset the marking bitmaps before/after GC cycle, the resetting may not not needed for each region. e.g. when `top_bitmap == bottom`(immediate trash regions?) or the region is not current gc generation.
>> 2. Withe large ShenandoahParallelRegionStride, each task will get large number of successive regions, e.g. worker 0 will process region 1 to region 1024, in this way it is not possible to make sure the actual workload is evenly distributed to all workers, some of the workers may have most of the regions need bitmap reset, some of the worker may not really do any actual bitmap reset at all. 
>> 
>> A smaller parallel region stride value will help with the workload distribution and also make it adaptive to different number of workers, it should be also working just fine with "worker surge"
>
> In the JBS bug report, I attached a test I did for this, I have tested value from 1 to 4096:
> 
> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -XX:ShenandoahParallelRegionStride=<Stride Value>-jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
> 
> 
> 
> [1]
> [77.444s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3078 us) (n = 14) (lvls, us = 1172, 1289, 1328, 1406, 14780)
> [77.444s][info][gc,stats ] Concurrent Reset After Collect = 0.044 s (a = 3150 us) (n = 14) (lvls, us = 1074, 1504, 1895, 4121, 8952)
> 
> [2]
> [77.304s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3036 us) (n = 14) (lvls, us = 1152, 1211, 1289, 1328, 14872)
> [77.305s][info][gc,stats ] Concurrent Reset After Collect = 0.046 s (a = 3297 us) (n = 14) (lvls, us = 939, 1602, 2148, 3945, 8744)
> 
> 
> [4]
> [76.898s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3048 us) (n = 14) (lvls, us = 1152, 1230, 1270, 1328, 14989)
> [76.898s][info][gc,stats ] Concurrent Reset After Collect = 0.045 s (a = 3215 us) (n = 14) (lvls, us = 1016, 1309, 1914, 3301, 7076)
> 
> [8]
> [77.916s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3067 us) (n = 14) (lvls, us = 1152, 1211, 1270, 1309, 15091)
> [77.916s][info][gc,stats ] Concurrent Reset After Collect = 0.043 s (a = 3050 us) (n = 14) (lvls, us = 1133, 1484, 1934, 3086, 8113)
> 
> [16]
> [77.071s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3019 us) (n = 14) (lvls, us = 1152, 1250, 1270, 1328, 14615)
> [77.071s][info][gc,stats ] Concurrent Reset After Collect = 0.046 s (a = 3284 us) (n = 14) (lvls, us = 932, 1523, 2090, 2930, 8841)
> 
> [32]
> [76.965s][info][gc,stats ] Concurrent Reset = 0.044 s (a = 3117 us) (n = 14) (lvls, us = 1191, 1211, 1328, 1348, 14768)
> [76.965s][info][gc,stats ] Concurrent Reset After Collect = 0.047 s (a = 3323 us) (n = 14) (lvls, us = 930, 1406, 1875, 4316, 8565)
> 
> 
> [64]
> [77.255s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3033 us) (n = 14) (lvls, us = 1152, 1211, 1270, 1406, 14635)
> [77.255s][info][gc,stats ] Concurrent Reset After Collect = 0.054 s (a = 3862 us) (n = 14) (lvls, us = 1133, 1504, 2852, 5508, 8947)
> 
> [128]
> [76.502s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3027 us) (n = 14) (lvls, us = 1133, 1230, 1250, 1426, 14264)
> [76.502s][info][gc,stats ] Concurrent Reset After Collect = 0.053 s (a = 3762 us) (n = 14) (lvls, us = 1172, 15...

Maybe amend the comment to explain that using a smaller value yields better task distribution for a lumpy workload like resetting bitmaps?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2582942471

From xpeng at openjdk.org  Tue Dec  2 23:28:58 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 2 Dec 2025 23:28:58 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v2]
In-Reply-To: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
Message-ID: <vvZn1rp9Ys869R2epKPrVvaatOv8ADKR3alc_CaZxqg=.0a76a1c9-7ba3-487d-b326-c0db40cfd0e6@github.com>

> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
> 
> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
> 
> Test result:
> 
> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
> 
> With the change:
> 
> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
> 
> Original:
> 
> 
> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
> 
> 
> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 58% reduction for the time, 100%+ improvement for the performance/speed. 
> 
> ### Other tests
> - [x] hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Add more comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28613/files
  - new: https://git.openjdk.org/jdk/pull/28613/files/06f27543..3b964995

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

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

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

From xpeng at openjdk.org  Tue Dec  2 23:29:00 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 2 Dec 2025 23:29:00 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v2]
In-Reply-To: <ELKo3crueRABaquE-xWwOs_p-fQYUPGWL1HMU0ZfYAs=.4a0260df-72d7-445d-83be-e5acbe8b47da@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <Li9mpQOvPyHQRrQo1RtNRE2KH0KTbjkL0N6uN-y2YcA=.736a6b43-f18d-4dc9-9e51-a893d4638573@github.com>
 <8YLFumpKphkiO-9PU9GbDz8g5XA388yLqD9xzlm9LUg=.ed2f7155-a371-4eeb-90bf-2bc45f63e900@github.com>
 <3MGUEGMsFxAnh_r0WE8hRt9FpH3ey0_xgKz_K3jaruQ=.4167d995-ba80-405f-bd17-9b77168d26ad@github.com>
 <6TAyVPTOcp6ykpzuzVuTP04UU8mk0tSkakJEinh4dnA=.4c43b199-09b5-4b9c-984d-c69cdca0b294@github.com>
 <ELKo3crueRABaquE-xWwOs_p-fQYUPGWL1HMU0ZfYAs=.4a0260df-72d7-445d-83be-e5acbe8b47da@github.com>
Message-ID: <yF4ieAZGSnuVAG0fLpFg-xR1dU2Wt48XEFLyy_iETqI=.0d180f2d-5611-420e-adfa-bb5f55de4950@github.com>

On Tue, 2 Dec 2025 22:13:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> In the JBS bug report, I attached a test I did for this, I have tested value from 1 to 4096:
>> 
>> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -XX:ShenandoahParallelRegionStride=<Stride Value>-jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
>> 
>> 
>> 
>> [1]
>> [77.444s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3078 us) (n = 14) (lvls, us = 1172, 1289, 1328, 1406, 14780)
>> [77.444s][info][gc,stats ] Concurrent Reset After Collect = 0.044 s (a = 3150 us) (n = 14) (lvls, us = 1074, 1504, 1895, 4121, 8952)
>> 
>> [2]
>> [77.304s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3036 us) (n = 14) (lvls, us = 1152, 1211, 1289, 1328, 14872)
>> [77.305s][info][gc,stats ] Concurrent Reset After Collect = 0.046 s (a = 3297 us) (n = 14) (lvls, us = 939, 1602, 2148, 3945, 8744)
>> 
>> 
>> [4]
>> [76.898s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3048 us) (n = 14) (lvls, us = 1152, 1230, 1270, 1328, 14989)
>> [76.898s][info][gc,stats ] Concurrent Reset After Collect = 0.045 s (a = 3215 us) (n = 14) (lvls, us = 1016, 1309, 1914, 3301, 7076)
>> 
>> [8]
>> [77.916s][info][gc,stats ] Concurrent Reset = 0.043 s (a = 3067 us) (n = 14) (lvls, us = 1152, 1211, 1270, 1309, 15091)
>> [77.916s][info][gc,stats ] Concurrent Reset After Collect = 0.043 s (a = 3050 us) (n = 14) (lvls, us = 1133, 1484, 1934, 3086, 8113)
>> 
>> [16]
>> [77.071s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3019 us) (n = 14) (lvls, us = 1152, 1250, 1270, 1328, 14615)
>> [77.071s][info][gc,stats ] Concurrent Reset After Collect = 0.046 s (a = 3284 us) (n = 14) (lvls, us = 932, 1523, 2090, 2930, 8841)
>> 
>> [32]
>> [76.965s][info][gc,stats ] Concurrent Reset = 0.044 s (a = 3117 us) (n = 14) (lvls, us = 1191, 1211, 1328, 1348, 14768)
>> [76.965s][info][gc,stats ] Concurrent Reset After Collect = 0.047 s (a = 3323 us) (n = 14) (lvls, us = 930, 1406, 1875, 4316, 8565)
>> 
>> 
>> [64]
>> [77.255s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3033 us) (n = 14) (lvls, us = 1152, 1211, 1270, 1406, 14635)
>> [77.255s][info][gc,stats ] Concurrent Reset After Collect = 0.054 s (a = 3862 us) (n = 14) (lvls, us = 1133, 1504, 2852, 5508, 8947)
>> 
>> [128]
>> [76.502s][info][gc,stats ] Concurrent Reset = 0.042 s (a = 3027 us) (n = 14) (lvls, us = 1133, 1230, 1250, 1426, 14264)
>> [76.502s][info][gc,stats ] Concur...
>
> Maybe amend the comment to explain that using a smaller value yields better task distribution for a lumpy workload like resetting bitmaps?

I have added more comments on ShenandoahResetBitmapClosure and the base class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2583109244

From xpeng at openjdk.org  Wed Dec  3 00:16:10 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 00:16:10 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v2]
In-Reply-To: <yF4ieAZGSnuVAG0fLpFg-xR1dU2Wt48XEFLyy_iETqI=.0d180f2d-5611-420e-adfa-bb5f55de4950@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <Li9mpQOvPyHQRrQo1RtNRE2KH0KTbjkL0N6uN-y2YcA=.736a6b43-f18d-4dc9-9e51-a893d4638573@github.com>
 <8YLFumpKphkiO-9PU9GbDz8g5XA388yLqD9xzlm9LUg=.ed2f7155-a371-4eeb-90bf-2bc45f63e900@github.com>
 <3MGUEGMsFxAnh_r0WE8hRt9FpH3ey0_xgKz_K3jaruQ=.4167d995-ba80-405f-bd17-9b77168d26ad@github.com>
 <6TAyVPTOcp6ykpzuzVuTP04UU8mk0tSkakJEinh4dnA=.4c43b199-09b5-4b9c-984d-c69cdca0b294@github.com>
 <ELKo3crueRABaquE-xWwOs_p-fQYUPGWL1HMU0ZfYAs=.4a0260df-72d7-445d-83be-e5acbe8b47da@github.com>
 <yF4ieAZGSnuVAG0fLpFg-xR1dU2Wt48XEFLyy_iETqI=.0d180f2d-5611-420e-adfa-bb5f55de4950@github.com>
Message-ID: <DhyUfimAMYXSArnAvXmiaVDnRtq9o-7QqOyEjnGNzh0=.dc6f59f9-e5a9-4155-b68e-38a15c8b7e2d@github.com>

On Tue, 2 Dec 2025 23:24:11 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Maybe amend the comment to explain that using a smaller value yields better task distribution for a lumpy workload like resetting bitmaps?
>
> I have added more comments on ShenandoahResetBitmapClosure and the base class.

>Can we make this change more "generic"?

I thought about making it more "generic", the current design with new method `parallel_region_stride` make it possible to customize the behavior if needed.

I was looking into other closures which may have similar problems but impact should be much smaller than this one:
1. ShenandoahMergeWriteTable:  Copy the write-version of the card-table into the read-version, clearing the write-copy, only for old gen.
2. ShenandoahEnsureHeapActiveClosure: Make sure regions are in good state: committed, active, clean, it may commit region if the region is not committed. Only in FullGC, also it is not threa-safe(but should be)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2583186822

From kdnilsen at openjdk.org  Wed Dec  3 01:00:11 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 3 Dec 2025 01:00:11 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
Message-ID: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>

On Tue, 2 Dec 2025 18:40:16 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code:
>> 
>> * ShenandoahAllocator: base class the allocator, most of the allocation code is in the class.
>> * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and  `_yield_to_safepoint` to customize the allocator for mutator.
>> * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. 
>> * ShenandoahOldCollectorAllocator:  allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector`
>> 
>> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance:
>> 
>> 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. 
>> 
>> java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
>> 
>> 
>> Openjdk TIP:
>> 
>> ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events =====
>> ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events =====
>> ===== DaCapo tail laten...
>
> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 255 commits:
> 
>  - Add missing header for ShenandoahFreeSetPartitionId
>  - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
>  - Fix a typo
>  - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
>  - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
>  - Port the fix of JDK-8372566
>  - Merge branch 'master' into cas-alloc-1
>  - Merge remote-tracking branch 'origin/master' into cas-alloc-1
>  - Remove junk code
>  - Remove unnecessary change and tidy up
>  - ... and 245 more: https://git.openjdk.org/jdk/compare/79e99bb0...7980c039

I'm still reading through the code, but have these comments far...

src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 80:

> 78:           break;
> 79:         case ShenandoahFreeSetPartitionId::OldCollector:
> 80:           _free_set->recompute_total_used</* UsedByMutatorChanged */ true,

These parameters seem overly conservative.  Can we distinguish what needs to be recomputed?
Normally, OldCollector allocation does not change UsedByMutator or UsedByCollector.  It will only change MutatorEmpties if we did flip_to_old.  It will normally not changed OldCollectorEmpties (unless it flips multiple mutator to OldCollector.  if might flip one region from mutator, but that region will not be empty after we allocate fro it...

src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 100:

> 98: HeapWord* ShenandoahAllocator<ALLOC_PARTITION>::attempt_allocation(ShenandoahAllocRequest& req, bool& in_new_region) {
> 99:   if (_alloc_region_count == 0u) {
> 100:     ShenandoahHeapLocker locker(ShenandoahHeap::heap()->lock(), _yield_to_safepoint);

Looking for more comments here as well.  What does it mean that _alloc_region_count == 0?  Does this mean we have not yet initialized the directly allocatable regions (following a particular GC event)?  Or does it mean that we have depleted all of the available regions and we are out of memory? In the first case, it seems we would want to replenish our supply of directly allocatable regions while we hold the GC lock.  In the second case, it seems there's really no value in even attempting a slow allocation.  (If we were unable to refresh our directly allocatable regions, then it will not find allocatable memory even on the other side of the heap lock...)

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

> 119: template <ShenandoahFreeSetPartitionId ALLOC_PARTITION>
> 120: HeapWord* ShenandoahAllocator<ALLOC_PARTITION>::attempt_allocation_slow(ShenandoahAllocRequest& req, bool& in_new_region) {
> 121:   ShenandoahHeapLocker locker(ShenandoahHeap::heap()->lock(), _yield_to_safepoint);

I think this is an error.  We don't want to acquire the lock here.  We also don't want to introduce accounting_update here.  Instead, I think these belong before line 130, in case we need to refresh the alloc regions.

src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 155:

> 153:   size_t min_free_words = req.is_lab_alloc() ? req.min_size() : req.size();
> 154:   ShenandoahHeapRegion* r = _free_set->find_heap_region_for_allocation(ALLOC_PARTITION, min_free_words, req.is_lab_alloc(), in_new_region);
> 155:   // The region returned by find_heap_region_for_allocation must have sufficient free space for the allocation it if it is not nullptr

comment has an extra "it"

src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 158:

> 156:   if (r != nullptr) {
> 157:     bool ready_for_retire = false;
> 158:     obj = atomic_allocate_in(r, false, req, in_new_region, ready_for_retire);

Not sure why we use atomic_allocate_in() here.  We hold the heap lock so we don't need to use atomic operations.  
We should clarify with comments.

src/hotspot/share/gc/shenandoah/shenandoahAllocator.hpp line 69:

> 67: 
> 68:   // Attempt to allocate in shared alloc regions, the allocation attempt is done with atomic operation w/o
> 69:   // holding heap lock.

I would rewrite comment:
// Attempt to allocate in a shared alloc region using atomic operation without holding the heap lock.
// Returns nullptr and overwrites regions_ready_for_refresh with the number of shared alloc regions that are ready
// to be retired if it is unable to satisfy the allocation request from the existing shared alloc regions.

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

PR Review: https://git.openjdk.org/jdk/pull/26171#pullrequestreview-3532274683
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2582914041
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2582950768
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2582966259
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2582922617
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2582936150
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2582959962

From kdnilsen at openjdk.org  Wed Dec  3 01:00:12 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 3 Dec 2025 01:00:12 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
 <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
Message-ID: <30wgBRAA7e-TzwsWTFagwcJdAxRcOeFD6-WJS-ashhA=.05995833-528a-4dec-820f-0307bf769520@github.com>

On Tue, 2 Dec 2025 22:00:17 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 pull request now contains 255 commits:
>> 
>>  - Add missing header for ShenandoahFreeSetPartitionId
>>  - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
>>  - Fix a typo
>>  - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
>>  - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
>>  - Port the fix of JDK-8372566
>>  - Merge branch 'master' into cas-alloc-1
>>  - Merge remote-tracking branch 'origin/master' into cas-alloc-1
>>  - Remove junk code
>>  - Remove unnecessary change and tidy up
>>  - ... and 245 more: https://git.openjdk.org/jdk/compare/79e99bb0...7980c039
>
> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 80:
> 
>> 78:           break;
>> 79:         case ShenandoahFreeSetPartitionId::OldCollector:
>> 80:           _free_set->recompute_total_used</* UsedByMutatorChanged */ true,
> 
> These parameters seem overly conservative.  Can we distinguish what needs to be recomputed?
> Normally, OldCollector allocation does not change UsedByMutator or UsedByCollector.  It will only change MutatorEmpties if we did flip_to_old.  It will normally not changed OldCollectorEmpties (unless it flips multiple mutator to OldCollector.  if might flip one region from mutator, but that region will not be empty after we allocate fro it...

I suppose we could use conservative values for a first implementation, as long as we file a "low priority" ticket to come back and revisit for improved efficiency at a later time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2582916275

From wkemper at openjdk.org  Wed Dec  3 01:07:03 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Dec 2025 01:07:03 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v2]
In-Reply-To: <vvZn1rp9Ys869R2epKPrVvaatOv8ADKR3alc_CaZxqg=.0a76a1c9-7ba3-487d-b326-c0db40cfd0e6@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <vvZn1rp9Ys869R2epKPrVvaatOv8ADKR3alc_CaZxqg=.0a76a1c9-7ba3-487d-b326-c0db40cfd0e6@github.com>
Message-ID: <yyRSui7fx0RlQ8X2hayUbekjFqfGel5xBG5c8azUE-I=.923f8d13-d828-47f6-bf5e-5af06c731f39@github.com>

On Tue, 2 Dec 2025 23:28:58 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
>> 
>> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
>> 
>> Test result:
>> 
>> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
>> 
>> With the change:
>> 
>> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
>> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
>> 
>> Original:
>> 
>> 
>> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
>> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
>> 
>> 
>> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 58% reduction for the time, 100%+ improvement for the performance/speed. 
>> 
>> ### Other tests
>> - [x] hotspot_gc_shenandoah
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more comments.

Looks good to me.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28613#pullrequestreview-3532721468

From xpeng at openjdk.org  Wed Dec  3 01:09:03 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 01:09:03 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <30wgBRAA7e-TzwsWTFagwcJdAxRcOeFD6-WJS-ashhA=.05995833-528a-4dec-820f-0307bf769520@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
 <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
 <30wgBRAA7e-TzwsWTFagwcJdAxRcOeFD6-WJS-ashhA=.05995833-528a-4dec-820f-0307bf769520@github.com>
Message-ID: <HZ09NfolFLPIA8BX7cIcGHiOeCwGYI8RCP920lbKCzI=.c320081a-6730-434b-9a12-b2a414023dcb@github.com>

On Tue, 2 Dec 2025 22:01:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 80:
>> 
>>> 78:           break;
>>> 79:         case ShenandoahFreeSetPartitionId::OldCollector:
>>> 80:           _free_set->recompute_total_used</* UsedByMutatorChanged */ true,
>> 
>> These parameters seem overly conservative.  Can we distinguish what needs to be recomputed?
>> Normally, OldCollector allocation does not change UsedByMutator or UsedByCollector.  It will only change MutatorEmpties if we did flip_to_old.  It will normally not changed OldCollectorEmpties (unless it flips multiple mutator to OldCollector.  if might flip one region from mutator, but that region will not be empty after we allocate fro it...
>
> I suppose we could use conservative values for a first implementation, as long as we file a "low priority" ticket to come back and revisit for improved efficiency at a later time.

We don't really know what need to be recompute until the allocation finishes, we can make it less  conservative, but then we needs more code branches here because the template methods require explicit template parameters.

I'll create to ticket to follow up on this, given that I also want to see if we can defer the recomputation to the read side, if we can do that we don't even need the ShenandoahHeapAccountingUpdater here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2583271726

From xpeng at openjdk.org  Wed Dec  3 01:12:23 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 01:12:23 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
 <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
Message-ID: <ECi5HN6NzZH0YUjTSonuKtMzeLXM9i5O-rygq_X5rKI=.76450f25-56d7-46dd-8513-49424772acb9@github.com>

On Tue, 2 Dec 2025 22:16:56 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 pull request now contains 255 commits:
>> 
>>  - Add missing header for ShenandoahFreeSetPartitionId
>>  - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
>>  - Fix a typo
>>  - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
>>  - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
>>  - Port the fix of JDK-8372566
>>  - Merge branch 'master' into cas-alloc-1
>>  - Merge remote-tracking branch 'origin/master' into cas-alloc-1
>>  - Remove junk code
>>  - Remove unnecessary change and tidy up
>>  - ... and 245 more: https://git.openjdk.org/jdk/compare/79e99bb0...7980c039
>
> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 100:
> 
>> 98: HeapWord* ShenandoahAllocator<ALLOC_PARTITION>::attempt_allocation(ShenandoahAllocRequest& req, bool& in_new_region) {
>> 99:   if (_alloc_region_count == 0u) {
>> 100:     ShenandoahHeapLocker locker(ShenandoahHeap::heap()->lock(), _yield_to_safepoint);
> 
> Looking for more comments here as well.  What does it mean that _alloc_region_count == 0?  Does this mean we have not yet initialized the directly allocatable regions (following a particular GC event)?  Or does it mean that we have depleted all of the available regions and we are out of memory? In the first case, it seems we would want to replenish our supply of directly allocatable regions while we hold the GC lock.  In the second case, it seems there's really no value in even attempting a slow allocation.  (If we were unable to refresh our directly allocatable regions, then it will not find allocatable memory even on the other side of the heap lock...)

I'll add comments on this, _alloc_region_count == 0 means we don't want to use any shared alloc region, it will also allocate with a heap lock, ideally the performance should be same as before, so it always simply find a region with enough space and allocate in the region.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2583283894

From xpeng at openjdk.org  Wed Dec  3 01:17:43 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 01:17:43 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
 <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
Message-ID: <XJncGwU5cFnUFMs2gadJQudmq4AeIWVeiVKOqZYuZbs=.f640d4a1-f5bd-4b1e-88f3-df669671e4c9@github.com>

On Tue, 2 Dec 2025 22:24:55 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 pull request now contains 255 commits:
>> 
>>  - Add missing header for ShenandoahFreeSetPartitionId
>>  - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
>>  - Fix a typo
>>  - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
>>  - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
>>  - Port the fix of JDK-8372566
>>  - Merge branch 'master' into cas-alloc-1
>>  - Merge remote-tracking branch 'origin/master' into cas-alloc-1
>>  - Remove junk code
>>  - Remove unnecessary change and tidy up
>>  - ... and 245 more: https://git.openjdk.org/jdk/compare/79e99bb0...7980c039
>
> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 121:
> 
>> 119: template <ShenandoahFreeSetPartitionId ALLOC_PARTITION>
>> 120: HeapWord* ShenandoahAllocator<ALLOC_PARTITION>::attempt_allocation_slow(ShenandoahAllocRequest& req, bool& in_new_region) {
>> 121:   ShenandoahHeapLocker locker(ShenandoahHeap::heap()->lock(), _yield_to_safepoint);
> 
> I think this is an error.  We don't want to acquire the lock here.  We also don't want to introduce accounting_update here.  Instead, I think these belong before line 130, in case we need to refresh the alloc regions.

It is not an error, before calling into attempt_allocation_slow, it already called attempt_allocation_in_alloc_regions once and failed to allocate, slow path is always with heap lock.

After taking the lock, we should try the attempt_allocation_in_alloc_regions right away, because other mutator thread may have refreshed the alloc regions while holding the lock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2583295858

From xpeng at openjdk.org  Wed Dec  3 01:17:44 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 01:17:44 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <XJncGwU5cFnUFMs2gadJQudmq4AeIWVeiVKOqZYuZbs=.f640d4a1-f5bd-4b1e-88f3-df669671e4c9@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
 <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
 <XJncGwU5cFnUFMs2gadJQudmq4AeIWVeiVKOqZYuZbs=.f640d4a1-f5bd-4b1e-88f3-df669671e4c9@github.com>
Message-ID: <ZCR0vZWrw5CpPYu8OccPxcZrWdXqft2zRcliL9Y2Xcc=.75f138e1-9a15-42a5-b04f-3088fdfde63f@github.com>

On Wed, 3 Dec 2025 01:13:41 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 121:
>> 
>>> 119: template <ShenandoahFreeSetPartitionId ALLOC_PARTITION>
>>> 120: HeapWord* ShenandoahAllocator<ALLOC_PARTITION>::attempt_allocation_slow(ShenandoahAllocRequest& req, bool& in_new_region) {
>>> 121:   ShenandoahHeapLocker locker(ShenandoahHeap::heap()->lock(), _yield_to_safepoint);
>> 
>> I think this is an error.  We don't want to acquire the lock here.  We also don't want to introduce accounting_update here.  Instead, I think these belong before line 130, in case we need to refresh the alloc regions.
>
> It is not an error, before calling into attempt_allocation_slow, it already called attempt_allocation_in_alloc_regions once and failed to allocate, slow path is always with heap lock.
> 
> After taking the lock, we should try the attempt_allocation_in_alloc_regions right away, because other mutator thread may have refreshed the alloc regions while holding the lock.

accounting_update is required for slow path, but you are right, it can be moved to somewhere later, e.g. line 128.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2583298253

From xpeng at openjdk.org  Wed Dec  3 01:21:56 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 01:21:56 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
 <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
Message-ID: <CbkgfXjrfLHTYCudrOSi9k5FRrptwfM2GRp9TdzgfvU=.5d89a750-5513-49e0-ade7-7fbdd0ce2c27@github.com>

On Tue, 2 Dec 2025 22:10:34 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 pull request now contains 255 commits:
>> 
>>  - Add missing header for ShenandoahFreeSetPartitionId
>>  - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
>>  - Fix a typo
>>  - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
>>  - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
>>  - Port the fix of JDK-8372566
>>  - Merge branch 'master' into cas-alloc-1
>>  - Merge remote-tracking branch 'origin/master' into cas-alloc-1
>>  - Remove junk code
>>  - Remove unnecessary change and tidy up
>>  - ... and 245 more: https://git.openjdk.org/jdk/compare/79e99bb0...7980c039
>
> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 158:
> 
>> 156:   if (r != nullptr) {
>> 157:     bool ready_for_retire = false;
>> 158:     obj = atomic_allocate_in(r, false, req, in_new_region, ready_for_retire);
> 
> Not sure why we use atomic_allocate_in() here.  We hold the heap lock so we don't need to use atomic operations.  
> We should clarify with comments.

It is not really necessary to `atomic_allocate_in` here, but I wanted reuse some of the codes in atomic_allocate_in, we can discuss this later, I can change it back to non-atomic version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2583304908

From duke at openjdk.org  Wed Dec  3 07:31:42 2025
From: duke at openjdk.org (Rui Li)
Date: Wed, 3 Dec 2025 07:31:42 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when soft
 max takes effect
Message-ID: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>

Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 

Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:


available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
soft_tail = Xmx - soft_max
if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 


The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.


Suggested fix: when deciding when to trigger gc, use logic similar to below:

mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
available = mutator_soft_capacity - used;
if (available < mutator_soft_capacity) // trigger gc
``` 

-------
This change also improved gc logging:

Before:

[6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
[6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B


After:

[8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
[8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
122, Reserved: 102M, Max free available in a single region: 1024K;

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

Commit messages:
 - 8372543: Shenandoah: undercalculated the available size when soft max takes effect

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

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

From aboldtch at openjdk.org  Wed Dec  3 09:14:28 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Dec 2025 09:14:28 GMT
Subject: RFR: 8319158: Parallel: Make TestObjectTenuringFlags use
 createTestJavaProcessBuilder
In-Reply-To: <5HbSzSNnNDiViXu6CzD_KsLbB4dpnC4VQjVpjDHqLm0=.4bce9f53-e4f1-44e2-95e5-ffa1a45be57d@github.com>
References: <5HbSzSNnNDiViXu6CzD_KsLbB4dpnC4VQjVpjDHqLm0=.4bce9f53-e4f1-44e2-95e5-ffa1a45be57d@github.com>
Message-ID: <PNnQFJ7ZVZqEfjWFtAXeblHaDlsuuqrlGtJijnDR9Lg=.a193f246-f027-4077-8000-99c8678c6697@github.com>

On Sat, 29 Nov 2025 18:22:42 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Summary of change:
> 
> executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
> @requires condition is expanded to include flags used in the test so that external flag settings don't disturb them.
> 
> Testing:
> HS Tiers 1 and 2
> Ran with all flag combinations in CI

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28567#pullrequestreview-3533963275

From rsunderbabu at openjdk.org  Wed Dec  3 09:25:01 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 3 Dec 2025 09:25:01 GMT
Subject: Integrated: 8319158: Parallel: Make TestObjectTenuringFlags use
 createTestJavaProcessBuilder
In-Reply-To: <5HbSzSNnNDiViXu6CzD_KsLbB4dpnC4VQjVpjDHqLm0=.4bce9f53-e4f1-44e2-95e5-ffa1a45be57d@github.com>
References: <5HbSzSNnNDiViXu6CzD_KsLbB4dpnC4VQjVpjDHqLm0=.4bce9f53-e4f1-44e2-95e5-ffa1a45be57d@github.com>
Message-ID: <h404_GM3TvnVKSav1KSOwt7yc1Gvls3hFNmAH4etT-4=.0b246d00-455b-472c-a0fd-638dd3e8868a@github.com>

On Sat, 29 Nov 2025 18:22:42 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Summary of change:
> 
> executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
> @requires condition is expanded to include flags used in the test so that external flag settings don't disturb them.
> 
> Testing:
> HS Tiers 1 and 2
> Ran with all flag combinations in CI

This pull request has now been integrated.

Changeset: a25e6f64
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a25e6f6462a5d77a2cb0dcec4f74e5e25d8565c4
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8319158: Parallel: Make TestObjectTenuringFlags use createTestJavaProcessBuilder

Reviewed-by: stefank, aboldtch

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

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

From eosterlund at openjdk.org  Wed Dec  3 09:28:52 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 3 Dec 2025 09:28:52 GMT
Subject: RFR: 8372738: ZGC: C2 allocation reloc promotion deopt race [v2]
In-Reply-To: <oU1CT54oXHYfzZreMNxQ_BBwx9x3NsB_zUItyodpNYY=.03ee8815-5d62-456e-a2b4-ef85b534bfc6@github.com>
References: <_II-BLtqOWNsgXJn-xs0SXfRGkflp0JfOISA6CZowXE=.ec9fe0f6-ff71-40f0-8223-7283e17afb47@github.com>
 <z0TttzVfjSBuyrvuSUgz6BjaQEG9Pf-BCGlTBec2Rsk=.c59e5a8c-0ff6-47db-89db-2568fef52f8f@github.com>
 <oU1CT54oXHYfzZreMNxQ_BBwx9x3NsB_zUItyodpNYY=.03ee8815-5d62-456e-a2b4-ef85b534bfc6@github.com>
Message-ID: <z309U0a_O16n0aJ_VAtBzR8tec9eg1N8Yv858mw5sqE=.bd6625ca-927e-49d9-810d-0342142fe8e9@github.com>

On Tue, 2 Dec 2025 14:30:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   StefanK comments
>
> Marked as reviewed by aboldtch (Reviewer).

Thanks for the reviews @xmas92 and @stefank!

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

PR Comment: https://git.openjdk.org/jdk/pull/28558#issuecomment-3605881911

From stefank at openjdk.org  Wed Dec  3 09:30:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Dec 2025 09:30:51 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <IUfN20CkPlSwyTdMJq8oQA3JsYb9oGUfp6LUHk3zGEc=.4dc5d479-ca46-4346-9537-ed610ce2082a@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
 <IUfN20CkPlSwyTdMJq8oQA3JsYb9oGUfp6LUHk3zGEc=.4dc5d479-ca46-4346-9537-ed610ce2082a@github.com>
Message-ID: <9-yPj5BYtvHE5AU4P9qJw1x__I7u_SV9GQHcAl4JXRk=.4ce1f46a-1591-44b0-94e4-bdb29a460d53@github.com>

On Sat, 29 Nov 2025 08:28:29 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
>> 
>> Testing:
>> HS Tiers 1 and 2 
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing the requires condition

> I guess you mean https://github.com/openjdk/jdk/pull/28566. I will restructure this test along those lines.

Yes, you are right.

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

PR Comment: https://git.openjdk.org/jdk/pull/28508#issuecomment-3605888987

From eosterlund at openjdk.org  Wed Dec  3 09:31:53 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 3 Dec 2025 09:31:53 GMT
Subject: Integrated: 8372738: ZGC: C2 allocation reloc promotion deopt race
In-Reply-To: <_II-BLtqOWNsgXJn-xs0SXfRGkflp0JfOISA6CZowXE=.ec9fe0f6-ff71-40f0-8223-7283e17afb47@github.com>
References: <_II-BLtqOWNsgXJn-xs0SXfRGkflp0JfOISA6CZowXE=.ec9fe0f6-ff71-40f0-8223-7283e17afb47@github.com>
Message-ID: <RbOnF7YAe8Lb_rVw56Bn_QU2UqlZtjtg3kFz4D0Q32M=.25fe0613-f217-4fbd-9b08-e2a9a6126f6a@github.com>

On Fri, 28 Nov 2025 15:11:07 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> In https://bugs.openjdk.org/browse/JDK-8371200 a race was handled between flip promoting objects, their promotion barriers, tenuring threshold selection and signalling to the JIT slow path allocation code to deoptimize. It made sure that flip promoted objects are made old before a handshake with the Java threads, and ran promotion barriers to erase any raw nulls after the handshake. This order was crucial to the fix.
> 
> Now unfortunately, there is a related problem for relocate promoting objects. Such objects run the promotion barriers before the object becomes old, which is the signal for the JIT allocation slow path code to deopt. Unfortunately, the order should be the opposite, similar to flip promoted objects. I propose signalling that relocate promoting pages are marked as relocate promoted during relocation set selection, and include that as a condition for deopt in the allocation slow path. The relocation set selection runs before the handshake, hence ensuring that promotion barriers won't race with JIT compiled code that has elided barriers.
> 
> T1-5 tests look good. The test that failed before reproduces an observable issue without the fix and not after the fix.

This pull request has now been integrated.

Changeset: 3e04e114
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e04e11482605e7734ef75bc477fe31107988f42
Stats:     96 lines in 8 files changed: 61 ins; 11 del; 24 mod

8372738: ZGC: C2 allocation reloc promotion deopt race

Reviewed-by: aboldtch, stefank

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

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

From shade at openjdk.org  Wed Dec  3 10:14:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Dec 2025 10:14:51 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v2]
In-Reply-To: <vvZn1rp9Ys869R2epKPrVvaatOv8ADKR3alc_CaZxqg=.0a76a1c9-7ba3-487d-b326-c0db40cfd0e6@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <vvZn1rp9Ys869R2epKPrVvaatOv8ADKR3alc_CaZxqg=.0a76a1c9-7ba3-487d-b326-c0db40cfd0e6@github.com>
Message-ID: <_UCh_KR6-uzVFOJ9MM-gK3gsTessZ03FuecOFkS2F8c=.86fbe32d-b450-4285-8906-ead7bd003b8f@github.com>

On Tue, 2 Dec 2025 23:28:58 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
>> 
>> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
>> 
>> Test result:
>> 
>> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
>> 
>> With the change:
>> 
>> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
>> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
>> 
>> Original:
>> 
>> 
>> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
>> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
>> 
>> 
>> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 58% reduction for the time, 100%+ improvement for the performance/speed. 
>> 
>> ### Other tests
>> - [x] hotspot_gc_shenandoah
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more comments.

Changes requested by shade (Reviewer).

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

> 86:   // Using a smaller value here yields better task distribution for a lumpy workload. The task will be split
> 87:   // into smaller batches with 8 regions in batch, the worker processes more regions w/o needs to reset bitmaps
> 88:   // will process more batches, but overall all workers will be saturated throughout the whole concurrent reset phase.

I have a very general comment about writing comments like this one. This entire block of prose is really excessive, is set up to be outdated (are you tracking the real behavior of `SH::parallel_heap_region_iterate` and its magical `4096`?), and can be boiled down to much more succinct:


Bitmap reset task is heavy-weight and benefits from much smaller tasks than the default.

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

> 117:   // ShenandoahHeap::parallel_heap_region_iterate will derive a reasonable value based
> 118:   // on active worker threads and number of regions.
> 119:   // For some lumpy workload, the value can be overridden for better task distribution.

Again, excessive. You can just drop the comment; its purpose is obvious from the code.

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

PR Review: https://git.openjdk.org/jdk/pull/28613#pullrequestreview-3534247421
PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2584465890
PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2584468632

From aboldtch at openjdk.org  Wed Dec  3 10:35:51 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Dec 2025 10:35:51 GMT
Subject: RFR: 8372995: SerialGC: Allow
 SerialHeap::allocate_loaded_archive_space expand old_gen
Message-ID: <Scx90YV8jyGm0fbdFxePtTigD4k9YwOkyJEF3HfCt98=.3fb734d8-9e22-4fe0-850c-0bd62a18b7b9@github.com>

`SerialHeap::allocate_loaded_archive_space` does currently not expand the old gen when allocating the archive space. This will cause problems when a not streamed aot archive cannot fit within the initial old size.

I propose we change this work like `ParallelHeap::allocate_loaded_archive_space` where we allow for old generation expansion. 

The not streamed aot archive will now only be limited by the max old size rather than the initial old size.

* Testing
  * Running GHA
  * Running tier 1-5 on Oracle supported platforms

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

Commit messages:
 - SerialGC: Allow SerialHeap::allocate_loaded_archive_space expand old_gen

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

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

From ayang at openjdk.org  Wed Dec  3 10:54:47 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 10:54:47 GMT
Subject: RFR: 8372999: Parallel: Old generation min size constraint broken
Message-ID: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>

Adding a missed min-gen-size-checking before shrinking old-gen.

`TEST=serviceability/tmtools/jstat/GcCapacityTest.java JTREG="JAVA_OPTIONS=-XX:+UseParallelGC -XX:InitialRAMPercentage=0"` fails before and passes after the fix.

Test: tier1

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

Commit messages:
 - pgc-shrink-below-min

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

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

From jsikstro at openjdk.org  Wed Dec  3 10:55:23 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 10:55:23 GMT
Subject: RFR: 8372993: Serial: max_eden_size is too small after JDK-8368740
Message-ID: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>

Hello,

`_max_eden_size` does not represent the actual upper-limit of how large eden might grow. The upper-limit was changed in (JDK-8368740)[https://bugs.openjdk.org/browse/JDK-8368740], so that eden might now grow to be as large as the entire young generation. We run into an exception when trying to use this value through the MemoryUsage Java API. If the committed memory in eden is larger than `_max_eden_size`, we throw an exception in the Java constructor of MemoryUsage: https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/java/lang/management/MemoryUsage.java#L165-L168

Testing:
* Oracle's tier1-4

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

Commit messages:
 - 8372993: Serial: max_eden_size is too small after JDK-8368740

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

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

From ayang at openjdk.org  Wed Dec  3 10:59:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 10:59:52 GMT
Subject: RFR: 8372995: SerialGC: Allow
 SerialHeap::allocate_loaded_archive_space expand old_gen
In-Reply-To: <Scx90YV8jyGm0fbdFxePtTigD4k9YwOkyJEF3HfCt98=.3fb734d8-9e22-4fe0-850c-0bd62a18b7b9@github.com>
References: <Scx90YV8jyGm0fbdFxePtTigD4k9YwOkyJEF3HfCt98=.3fb734d8-9e22-4fe0-850c-0bd62a18b7b9@github.com>
Message-ID: <6M-VvRFpMySpsXjAc2x54gILExHY29KktlaQY6c8uaw=.ecc56ae4-a22d-4723-bd0c-13fcc722f2c5@github.com>

On Wed, 3 Dec 2025 10:24:18 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `SerialHeap::allocate_loaded_archive_space` does currently not expand the old gen when allocating the archive space. This will cause problems when a not streamed aot archive cannot fit within the initial old size.
> 
> I propose we change this work like `ParallelHeap::allocate_loaded_archive_space` where we allow for old generation expansion. 
> 
> The not streamed aot archive will now only be limited by the max old size rather than the initial old size.
> 
> * Testing
>   * Running GHA
>   * Running tier 1-5 on Oracle supported platforms

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28628#pullrequestreview-3534477647

From jsikstro at openjdk.org  Wed Dec  3 11:13:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 11:13:07 GMT
Subject: RFR: 8372993: Serial: max_eden_size is too small after JDK-8368740
 [v2]
In-Reply-To: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
References: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
Message-ID: <bJUrf3ziPwTDNSrKxs0GREyoxtsvsZQwj-jMXdzZvEQ=.c74cbaa1-5f7b-45ad-b90f-16251abeddaa@github.com>

> Hello,
> 
> `_max_eden_size` does not represent the actual upper-limit of how large eden might grow. The upper-limit was changed in (JDK-8368740)[https://bugs.openjdk.org/browse/JDK-8368740], so that eden might now grow to be as large as the entire young generation. We run into an exception when trying to use this value through the MemoryUsage Java API. If the committed memory in eden is larger than `_max_eden_size`, we throw an exception in the Java constructor of MemoryUsage: https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/java/lang/management/MemoryUsage.java#L165-L168
> 
> Testing:
> * Oracle's tier1-4

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Adjust comment a bit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28630/files
  - new: https://git.openjdk.org/jdk/pull/28630/files/00b085ff..b01fb981

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

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

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

From ayang at openjdk.org  Wed Dec  3 11:18:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 11:18:36 GMT
Subject: RFR: 8372993: Serial: max_eden_size is too small after JDK-8368740
 [v2]
In-Reply-To: <bJUrf3ziPwTDNSrKxs0GREyoxtsvsZQwj-jMXdzZvEQ=.c74cbaa1-5f7b-45ad-b90f-16251abeddaa@github.com>
References: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
 <bJUrf3ziPwTDNSrKxs0GREyoxtsvsZQwj-jMXdzZvEQ=.c74cbaa1-5f7b-45ad-b90f-16251abeddaa@github.com>
Message-ID: <NQkZIyE2yb-GtZhwjaKMNxn-wsKWEnt43doFmnwr5y0=.92cd7d60-eb29-4ab4-afb7-95ea252f8b4b@github.com>

On Wed, 3 Dec 2025 11:13:07 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> `_max_eden_size` does not represent the actual upper-limit of how large eden might grow. The upper-limit was changed in (JDK-8368740)[https://bugs.openjdk.org/browse/JDK-8368740], so that eden might now grow to be as large as the entire young generation. We run into an exception when trying to use this value through the MemoryUsage Java API. If the committed memory in eden is larger than `_max_eden_size`, we throw an exception in the Java constructor of MemoryUsage: https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/java/lang/management/MemoryUsage.java#L165-L168
>> 
>> Testing:
>> * Oracle's tier1-4
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comment a bit

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28630#pullrequestreview-3534561985

From jsikstro at openjdk.org  Wed Dec  3 12:49:39 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 12:49:39 GMT
Subject: RFR: 8372993: Serial: max_eden_size is too small after JDK-8368740
 [v3]
In-Reply-To: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
References: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
Message-ID: <Jz55FZexwev3FgxsMe9d49MNm7DMODK_iaTgYsw3Xw4=.d808a73b-9f1d-454e-b99e-3677e78f0d63@github.com>

> Hello,
> 
> `_max_eden_size` does not represent the actual upper-limit of how large eden might grow. The upper-limit was changed in (JDK-8368740)[https://bugs.openjdk.org/browse/JDK-8368740], so that eden might now grow to be as large as the entire young generation. We run into an exception when trying to use this value through the MemoryUsage Java API. If the committed memory in eden is larger than `_max_eden_size`, we throw an exception in the Java constructor of MemoryUsage: https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/java/lang/management/MemoryUsage.java#L165-L168
> 
> Testing:
> * Oracle's tier1-4

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Test fix for TestNewSizeFlags.java to reflect bew max of young gen spaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28630/files
  - new: https://git.openjdk.org/jdk/pull/28630/files/b01fb981..db987454

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

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

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

From jsikstro at openjdk.org  Wed Dec  3 12:54:15 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 12:54:15 GMT
Subject: RFR: 8372995: SerialGC: Allow
 SerialHeap::allocate_loaded_archive_space expand old_gen
In-Reply-To: <Scx90YV8jyGm0fbdFxePtTigD4k9YwOkyJEF3HfCt98=.3fb734d8-9e22-4fe0-850c-0bd62a18b7b9@github.com>
References: <Scx90YV8jyGm0fbdFxePtTigD4k9YwOkyJEF3HfCt98=.3fb734d8-9e22-4fe0-850c-0bd62a18b7b9@github.com>
Message-ID: <SO9HiA5viwy0qDsJfBCvEbmatRaJQW9xAdAgi-3nM3Q=.f5c1ba98-c8fb-4e4d-8224-54a00dbd582b@github.com>

On Wed, 3 Dec 2025 10:24:18 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `SerialHeap::allocate_loaded_archive_space` does currently not expand the old gen when allocating the archive space. This will cause problems when a not streamed aot archive cannot fit within the initial old size.
> 
> I propose we change this work like `ParallelHeap::allocate_loaded_archive_space` where we allow for old generation expansion. 
> 
> The not streamed aot archive will now only be limited by the max old size rather than the initial old size.
> 
> * Testing
>   * Running GHA
>   * Running tier 1-5 on Oracle supported platforms

Looks good.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28628#pullrequestreview-3534898479

From ayang at openjdk.org  Wed Dec  3 13:03:24 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 13:03:24 GMT
Subject: RFR: 8372993: Serial: max_eden_size is too small after JDK-8368740
 [v3]
In-Reply-To: <Jz55FZexwev3FgxsMe9d49MNm7DMODK_iaTgYsw3Xw4=.d808a73b-9f1d-454e-b99e-3677e78f0d63@github.com>
References: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
 <Jz55FZexwev3FgxsMe9d49MNm7DMODK_iaTgYsw3Xw4=.d808a73b-9f1d-454e-b99e-3677e78f0d63@github.com>
Message-ID: <VctJoSzRrO0vzMxSXhPqizwCwx2fcLCrlyTXQgkeIkA=.9bcefeac-259f-46b9-83cf-49c818a5da6d@github.com>

On Wed, 3 Dec 2025 12:49:39 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> `_max_eden_size` does not represent the actual upper-limit of how large eden might grow. The upper-limit was changed in (JDK-8368740)[https://bugs.openjdk.org/browse/JDK-8368740], so that eden might now grow to be as large as the entire young generation. We run into an exception when trying to use this value through the MemoryUsage Java API. If the committed memory in eden is larger than `_max_eden_size`, we throw an exception in the Java constructor of MemoryUsage: https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/java/lang/management/MemoryUsage.java#L165-L168
>> 
>> Testing:
>> * Oracle's tier1-4
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix for TestNewSizeFlags.java to reflect bew max of young gen spaces

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28630#pullrequestreview-3534931540

From ayang at openjdk.org  Wed Dec  3 13:05:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 13:05:41 GMT
Subject: RFR: 8372999: Parallel: Old generation min size constraint broken
 [v2]
In-Reply-To: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
References: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
Message-ID: <lHfwKrxCNZC4PCx1624WNuuOZR7drG4gA037QP2ZNE0=.1b2b863e-1575-4a03-970f-bc6967d5972c@github.com>

> Adding a missed min-gen-size-checking before shrinking old-gen.
> 
> `TEST=serviceability/tmtools/jstat/GcCapacityTest.java JTREG="JAVA_OPTIONS=-XX:+UseParallelGC -XX:InitialRAMPercentage=0"` fails before and passes after the fix.
> 
> Test: tier1

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28629/files
  - new: https://git.openjdk.org/jdk/pull/28629/files/0c776b22..6fb8528f

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

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

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

From ayang at openjdk.org  Wed Dec  3 13:23:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 13:23:52 GMT
Subject: RFR: 8372999: Parallel: Old generation min size constraint broken
 [v3]
In-Reply-To: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
References: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
Message-ID: <7HpkdujwMM-l0frFpSLOI2WnSzvVVr5wqTkw3xmUXds=.97d20523-b857-4b24-8bf8-9d011abb629e@github.com>

> Adding a missed min-gen-size-checking before shrinking old-gen.
> 
> `TEST=serviceability/tmtools/jstat/GcCapacityTest.java JTREG="JAVA_OPTIONS=-XX:+UseParallelGC -XX:InitialRAMPercentage=0"` fails before and passes after the fix.
> 
> Test: tier1

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28629/files
  - new: https://git.openjdk.org/jdk/pull/28629/files/6fb8528f..61f27a47

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

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

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

From ayang at openjdk.org  Wed Dec  3 14:10:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 14:10:33 GMT
Subject: RFR: 8372999: Parallel: Old generation min size constraint broken
 [v4]
In-Reply-To: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
References: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
Message-ID: <jAqKG6rFVw_5dGCn-e0Wo2YXZ5kFFLee6OgIZHTNAzU=.6d662c54-66eb-4905-8841-4b0da9ea3b55@github.com>

> Adding a missed min-gen-size-checking before shrinking old-gen.
> 
> `TEST=serviceability/tmtools/jstat/GcCapacityTest.java JTREG="JAVA_OPTIONS=-XX:+UseParallelGC -XX:InitialRAMPercentage=0"` fails before and passes after the fix.
> 
> Test: tier1

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28629/files
  - new: https://git.openjdk.org/jdk/pull/28629/files/61f27a47..3af0c97b

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

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

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

From aboldtch at openjdk.org  Wed Dec  3 14:37:17 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Dec 2025 14:37:17 GMT
Subject: RFR: 8372993: Serial: max_eden_size is too small after JDK-8368740
 [v3]
In-Reply-To: <Jz55FZexwev3FgxsMe9d49MNm7DMODK_iaTgYsw3Xw4=.d808a73b-9f1d-454e-b99e-3677e78f0d63@github.com>
References: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
 <Jz55FZexwev3FgxsMe9d49MNm7DMODK_iaTgYsw3Xw4=.d808a73b-9f1d-454e-b99e-3677e78f0d63@github.com>
Message-ID: <IeZmi8zqkK11DTxS-L589Whe4zd3zoPE2bDyG1F-dx8=.9a9f506a-3fa5-40a3-9a54-5f32fe7dafb6@github.com>

On Wed, 3 Dec 2025 12:49:39 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> `_max_eden_size` does not represent the actual upper-limit of how large eden might grow. The upper-limit was changed in (JDK-8368740)[https://bugs.openjdk.org/browse/JDK-8368740], so that eden might now grow to be as large as the entire young generation. We run into an exception when trying to use this value through the MemoryUsage Java API. If the committed memory in eden is larger than `_max_eden_size`, we throw an exception in the Java constructor of MemoryUsage: https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/java/lang/management/MemoryUsage.java#L165-L168
>> 
>> Testing:
>> * Oracle's tier1-4
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix for TestNewSizeFlags.java to reflect bew max of young gen spaces

Looks good.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28630#pullrequestreview-3535351185

From stefank at openjdk.org  Wed Dec  3 14:37:18 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Dec 2025 14:37:18 GMT
Subject: RFR: 8372993: Serial: max_eden_size is too small after JDK-8368740
 [v3]
In-Reply-To: <Jz55FZexwev3FgxsMe9d49MNm7DMODK_iaTgYsw3Xw4=.d808a73b-9f1d-454e-b99e-3677e78f0d63@github.com>
References: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
 <Jz55FZexwev3FgxsMe9d49MNm7DMODK_iaTgYsw3Xw4=.d808a73b-9f1d-454e-b99e-3677e78f0d63@github.com>
Message-ID: <M7CyNnsBqaIVRNIPfFCxUxEV5UL4WIcXLsRnZjNL-xA=.7fbb13a8-8de6-4b6e-a447-7df883d6155f@github.com>

On Wed, 3 Dec 2025 12:49:39 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> `_max_eden_size` does not represent the actual upper-limit of how large eden might grow. The upper-limit was changed in (JDK-8368740)[https://bugs.openjdk.org/browse/JDK-8368740], so that eden might now grow to be as large as the entire young generation. We run into an exception when trying to use this value through the MemoryUsage Java API. If the committed memory in eden is larger than `_max_eden_size`, we throw an exception in the Java constructor of MemoryUsage: https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/java/lang/management/MemoryUsage.java#L165-L168
>> 
>> Testing:
>> * Oracle's tier1-4
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix for TestNewSizeFlags.java to reflect bew max of young gen spaces

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28630#pullrequestreview-3535353659

From jsikstro at openjdk.org  Wed Dec  3 14:37:19 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 14:37:19 GMT
Subject: RFR: 8372993: Serial: max_eden_size is too small after JDK-8368740
 [v3]
In-Reply-To: <VctJoSzRrO0vzMxSXhPqizwCwx2fcLCrlyTXQgkeIkA=.9bcefeac-259f-46b9-83cf-49c818a5da6d@github.com>
References: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
 <Jz55FZexwev3FgxsMe9d49MNm7DMODK_iaTgYsw3Xw4=.d808a73b-9f1d-454e-b99e-3677e78f0d63@github.com>
 <VctJoSzRrO0vzMxSXhPqizwCwx2fcLCrlyTXQgkeIkA=.9bcefeac-259f-46b9-83cf-49c818a5da6d@github.com>
Message-ID: <Ex0Dr-6GVp2gDt8N2asXlEtsYsuWa-lGmhpkyyKq5Go=.b8e138bb-55ae-47b0-ab73-e48417114707@github.com>

On Wed, 3 Dec 2025 13:00:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test fix for TestNewSizeFlags.java to reflect bew max of young gen spaces
>
> Marked as reviewed by ayang (Reviewer).

Thank you for the reviews @albertnetymk @xmas92 @stefank

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

PR Comment: https://git.openjdk.org/jdk/pull/28630#issuecomment-3607153040

From jsikstro at openjdk.org  Wed Dec  3 14:37:20 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 14:37:20 GMT
Subject: Integrated: 8372993: Serial: max_eden_size is too small after
 JDK-8368740
In-Reply-To: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
References: <imYdGEISz4RIzsysGF_SwOs5I64FdYMwzQDTi4I_YPo=.6029117a-2bf2-4723-a1c9-541b66133388@github.com>
Message-ID: <e17I9PDBF7fcNxhJB5htVFJ64jgZbBQCDA5zxnX6Tog=.e49042ea-2c8e-411f-8b36-537bde80675d@github.com>

On Wed, 3 Dec 2025 10:46:23 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> `_max_eden_size` does not represent the actual upper-limit of how large eden might grow. The upper-limit was changed in (JDK-8368740)[https://bugs.openjdk.org/browse/JDK-8368740], so that eden might now grow to be as large as the entire young generation. We run into an exception when trying to use this value through the MemoryUsage Java API. If the committed memory in eden is larger than `_max_eden_size`, we throw an exception in the Java constructor of MemoryUsage: https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/java/lang/management/MemoryUsage.java#L165-L168
> 
> Testing:
> * Oracle's tier1-4

This pull request has now been integrated.

Changeset: c0636734
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0636734bdf19de6ba41c127aef1f090010c6d90
Stats:     18 lines in 2 files changed: 17 ins; 0 del; 1 mod

8372993: Serial: max_eden_size is too small after JDK-8368740

Reviewed-by: ayang, aboldtch, stefank

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

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

From rsunderbabu at openjdk.org  Wed Dec  3 14:38:57 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 3 Dec 2025 14:38:57 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder [v3]
In-Reply-To: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
Message-ID: <autgJQmEuJ3lQkJ1e_lATd5QU__3UEJ1uOZaoaew-8I=.70b8f1cf-9dd4-4254-9938-be5918949893@github.com>

> Summary of change:
> executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
> `@requires vm.gc == null` - this line is added to skip runs that use GC flags in test vm options. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected").
> 
> Testing:
> HS Tiers 1 and 2 
> Ran with all flag combinations in CI

Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:

  test split into sections

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28508/files
  - new: https://git.openjdk.org/jdk/pull/28508/files/a3edb127..3d1f3226

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

  Stats: 60 lines in 1 file changed: 33 ins; 5 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/28508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28508/head:pull/28508

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

From rsunderbabu at openjdk.org  Wed Dec  3 14:41:49 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 3 Dec 2025 14:41:49 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder [v3]
In-Reply-To: <autgJQmEuJ3lQkJ1e_lATd5QU__3UEJ1uOZaoaew-8I=.70b8f1cf-9dd4-4254-9938-be5918949893@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
 <autgJQmEuJ3lQkJ1e_lATd5QU__3UEJ1uOZaoaew-8I=.70b8f1cf-9dd4-4254-9938-be5918949893@github.com>
Message-ID: <tltWMtjZDsdBiEyabzAG4yrTWgj5JDchywm-Ps_w3L0=.6cbd990f-9a74-40d1-bb80-376a9c98dc0d@github.com>

On Wed, 3 Dec 2025 14:38:57 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> 
>> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> 2. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected"). So, test is split into separate sections pertaining to GC requirements. @requires now has corresponding GC flag condition.
>> 3. Removal of WhiteBox dependency and few cleanups.
>> 
>> Testing:
>> HS Tiers 1 and 2 
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test split into sections

The latest changes have been tested with all flag combinations in CI

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

PR Comment: https://git.openjdk.org/jdk/pull/28508#issuecomment-3607183856

From stefank at openjdk.org  Wed Dec  3 14:44:09 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Dec 2025 14:44:09 GMT
Subject: RFR: 8372999: Parallel: Old generation min size constraint broken
 [v4]
In-Reply-To: <jAqKG6rFVw_5dGCn-e0Wo2YXZ5kFFLee6OgIZHTNAzU=.6d662c54-66eb-4905-8841-4b0da9ea3b55@github.com>
References: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
 <jAqKG6rFVw_5dGCn-e0Wo2YXZ5kFFLee6OgIZHTNAzU=.6d662c54-66eb-4905-8841-4b0da9ea3b55@github.com>
Message-ID: <b_CaDVQzP-zfUMeklogY49jdzPLy766E5ZwfolthxpI=.14cb9b70-d102-4f52-8a66-f9cd5509d4c1@github.com>

On Wed, 3 Dec 2025 14:10:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Adding a missed min-gen-size-checking before shrinking old-gen.
>> 
>> `TEST=serviceability/tmtools/jstat/GcCapacityTest.java JTREG="JAVA_OPTIONS=-XX:+UseParallelGC -XX:InitialRAMPercentage=0"` fails before and passes after the fix.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28629#pullrequestreview-3535395503

From stefank at openjdk.org  Wed Dec  3 15:02:44 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Dec 2025 15:02:44 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder [v3]
In-Reply-To: <autgJQmEuJ3lQkJ1e_lATd5QU__3UEJ1uOZaoaew-8I=.70b8f1cf-9dd4-4254-9938-be5918949893@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
 <autgJQmEuJ3lQkJ1e_lATd5QU__3UEJ1uOZaoaew-8I=.70b8f1cf-9dd4-4254-9938-be5918949893@github.com>
Message-ID: <SkTUIg2Mr17PIllwLMK54tRjFZBkUdJPtpeQhBfNS0o=.ef07acac-1f21-4608-b29f-993170e3004c@github.com>

On Wed, 3 Dec 2025 14:38:57 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> 
>> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> 2. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected"). So, test is split into separate sections pertaining to GC requirements. @requires now has corresponding GC flag condition.
>> 3. Removal of WhiteBox dependency and few cleanups.
>> 
>> Testing:
>> HS Tiers 1 and 2 
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test split into sections

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28508#pullrequestreview-3535481958

From jsikstro at openjdk.org  Wed Dec  3 15:13:21 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 15:13:21 GMT
Subject: RFR: 8372999: Parallel: Old generation min size constraint broken
 [v4]
In-Reply-To: <jAqKG6rFVw_5dGCn-e0Wo2YXZ5kFFLee6OgIZHTNAzU=.6d662c54-66eb-4905-8841-4b0da9ea3b55@github.com>
References: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
 <jAqKG6rFVw_5dGCn-e0Wo2YXZ5kFFLee6OgIZHTNAzU=.6d662c54-66eb-4905-8841-4b0da9ea3b55@github.com>
Message-ID: <7pHYqEd7kEp4xVQotSlenRollpQlfM5OSipORmB3hQ8=.9ed1c516-8f44-49a2-97a5-b7518717657a@github.com>

On Wed, 3 Dec 2025 14:10:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Adding a missed min-gen-size-checking before shrinking old-gen.
>> 
>> `TEST=serviceability/tmtools/jstat/GcCapacityTest.java JTREG="JAVA_OPTIONS=-XX:+UseParallelGC -XX:InitialRAMPercentage=0"` fails before and passes after the fix.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28629#pullrequestreview-3535532762

From aboldtch at openjdk.org  Wed Dec  3 15:22:16 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Dec 2025 15:22:16 GMT
Subject: RFR: 8373025: Test: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java
 may deadlock
Message-ID: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>

The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.

I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.

* Testing
  * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
  * GHA

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

Commit messages:
 - Fix the comment
 - 8373025: Test: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock

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

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

From stefank at openjdk.org  Wed Dec  3 15:22:17 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Dec 2025 15:22:17 GMT
Subject: RFR: 8373025: Test:
 test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock
In-Reply-To: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
References: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
Message-ID: <X4az-1Tc4ze5ZJfTwq--mKEeX6hciCVoTy9aHwyKmAM=.d49167d8-e812-4552-92b1-d788d64452cb@github.com>

On Wed, 3 Dec 2025 15:10:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
> 
> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
> 
> * Testing
>   * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
>   * GHA

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28638#pullrequestreview-3535569189

From aboldtch at openjdk.org  Wed Dec  3 15:24:32 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Dec 2025 15:24:32 GMT
Subject: RFR: 8372995: SerialGC: Allow
 SerialHeap::allocate_loaded_archive_space expand old_gen
In-Reply-To: <Scx90YV8jyGm0fbdFxePtTigD4k9YwOkyJEF3HfCt98=.3fb734d8-9e22-4fe0-850c-0bd62a18b7b9@github.com>
References: <Scx90YV8jyGm0fbdFxePtTigD4k9YwOkyJEF3HfCt98=.3fb734d8-9e22-4fe0-850c-0bd62a18b7b9@github.com>
Message-ID: <lDnLSwgpX5BkYoeoFnwHAR7vDqdAsyZ1VnBlUyKH1SA=.edb2c610-4005-45de-bd4e-8a907a6c0daa@github.com>

On Wed, 3 Dec 2025 10:24:18 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `SerialHeap::allocate_loaded_archive_space` does currently not expand the old gen when allocating the archive space. This will cause problems when a not streamed aot archive cannot fit within the initial old size.
> 
> I propose we change this work like `ParallelHeap::allocate_loaded_archive_space` where we allow for old generation expansion. 
> 
> The not streamed aot archive will now only be limited by the max old size rather than the initial old size.
> 
> * Testing
>   * Running GHA
>   * Running tier 1-5 on Oracle supported platforms

We need ot get this in a bit earlier than the normal 24h rule because of a dependent issue we want reviewed an integrated before the fork. 
Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28628#issuecomment-3607370120

From aboldtch at openjdk.org  Wed Dec  3 15:24:33 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Dec 2025 15:24:33 GMT
Subject: Integrated: 8372995: SerialGC: Allow
 SerialHeap::allocate_loaded_archive_space expand old_gen
In-Reply-To: <Scx90YV8jyGm0fbdFxePtTigD4k9YwOkyJEF3HfCt98=.3fb734d8-9e22-4fe0-850c-0bd62a18b7b9@github.com>
References: <Scx90YV8jyGm0fbdFxePtTigD4k9YwOkyJEF3HfCt98=.3fb734d8-9e22-4fe0-850c-0bd62a18b7b9@github.com>
Message-ID: <5UHL8YtaOIcZvI0eLvzTXrbhdOK8-Fj5DeJMsUky95M=.2f51d30e-bae5-46ec-844f-7781db414cdb@github.com>

On Wed, 3 Dec 2025 10:24:18 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `SerialHeap::allocate_loaded_archive_space` does currently not expand the old gen when allocating the archive space. This will cause problems when a not streamed aot archive cannot fit within the initial old size.
> 
> I propose we change this work like `ParallelHeap::allocate_loaded_archive_space` where we allow for old generation expansion. 
> 
> The not streamed aot archive will now only be limited by the max old size rather than the initial old size.
> 
> * Testing
>   * Running GHA
>   * Running tier 1-5 on Oracle supported platforms

This pull request has now been integrated.

Changeset: 3d54a802
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d54a802e38f425c7035c947758c887fec48e43a
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8372995: SerialGC: Allow SerialHeap::allocate_loaded_archive_space expand old_gen

Reviewed-by: ayang, jsikstro

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

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

From ayang at openjdk.org  Wed Dec  3 15:30:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 15:30:05 GMT
Subject: RFR: 8372999: Parallel: Old generation min size constraint broken
 [v4]
In-Reply-To: <jAqKG6rFVw_5dGCn-e0Wo2YXZ5kFFLee6OgIZHTNAzU=.6d662c54-66eb-4905-8841-4b0da9ea3b55@github.com>
References: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
 <jAqKG6rFVw_5dGCn-e0Wo2YXZ5kFFLee6OgIZHTNAzU=.6d662c54-66eb-4905-8841-4b0da9ea3b55@github.com>
Message-ID: <VBO3cIvYQXk2EeISTFeXlRRSzrXGIr7NrPEYww-Hr1Y=.bceafe11-f381-4ca4-90b6-883548b1482e@github.com>

On Wed, 3 Dec 2025 14:10:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Adding a missed min-gen-size-checking before shrinking old-gen.
>> 
>> `TEST=serviceability/tmtools/jstat/GcCapacityTest.java JTREG="JAVA_OPTIONS=-XX:+UseParallelGC -XX:InitialRAMPercentage=0"` fails before and passes after the fix.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review. Merging sooner to reduce CI noise.

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

PR Comment: https://git.openjdk.org/jdk/pull/28629#issuecomment-3607404965

From ayang at openjdk.org  Wed Dec  3 15:33:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 15:33:35 GMT
Subject: Integrated: 8372999: Parallel: Old generation min size constraint
 broken
In-Reply-To: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
References: <EDA1Lk2fZlEjtsGrh614FVlm_0ezC1YWymyASAUlE7s=.f111041b-319d-4d24-876c-08146093523f@github.com>
Message-ID: <_m3mtE21aCxSU7_t6a7SMYRJmkzIusY3K0ZYj_mKUoA=.694c1c87-878a-44cd-aa16-869b8cf8a3eb@github.com>

On Wed, 3 Dec 2025 10:42:53 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Adding a missed min-gen-size-checking before shrinking old-gen.
> 
> `TEST=serviceability/tmtools/jstat/GcCapacityTest.java JTREG="JAVA_OPTIONS=-XX:+UseParallelGC -XX:InitialRAMPercentage=0"` fails before and passes after the fix.
> 
> Test: tier1

This pull request has now been integrated.

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

8372999: Parallel: Old generation min size constraint broken

Reviewed-by: stefank, jsikstro

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

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

From eastigeevich at openjdk.org  Wed Dec  3 15:42:38 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 15:42:38 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>

> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>  
> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
> - Disable coherent icache.
> - Trap IC IVAU instructions.
> - Execute:
>    - `tlbi vae3is, xzr`
>    - `dsb sy`
>  
>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>  
> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
> 
> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
> 
> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
> 
> Changes include:
> 
> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
> 
> - Baseline
> 
> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1Errata1542419 -XX:+UseZGC -XX:ZYoungGCThreads=1 -XX:ZOldGC...

Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Fix linux-cross-compile build aarch64
 - Merge branch 'master' into JDK-8370947
 - Remove trailing whitespaces
 - Add support of deferred icache invalidation to other GCs and JIT
 - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence
 - Add jtreg test
 - Fix linux-cross-compile aarch64 build
 - Fix regressions for Java methods without field accesses
 - Fix code style
 - Correct ifdef; Add dsb after ic
 - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f

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

Changes: https://git.openjdk.org/jdk/pull/28328/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=12
  Stats: 879 lines in 25 files changed: 839 ins; 7 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/28328.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328

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

From ayang at openjdk.org  Wed Dec  3 15:54:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 15:54:58 GMT
Subject: RFR: 8373025: Test:
 test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock
In-Reply-To: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
References: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
Message-ID: <Sqf9IUHGmVIvnp3IVl-6tlFm9fAKdL9233eBmYF2bsI=.3c69d8aa-b1a9-428e-981b-cd529c859eb8@github.com>

On Wed, 3 Dec 2025 15:10:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
> 
> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
> 
> * Testing
>   * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
>   * GHA

test/hotspot/jtreg/gc/cslocker/TestCSLocker.java line 41:

> 39: public class TestCSLocker extends Thread
> 40: {
> 41:     static int timeoutMillis = 5000;

Seems unused now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28638#discussion_r2585663274

From aboldtch at openjdk.org  Wed Dec  3 16:00:19 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Dec 2025 16:00:19 GMT
Subject: RFR: 8373025: Test:
 test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock [v2]
In-Reply-To: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
References: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
Message-ID: <Hu4Qz747lCADaygr7PSw-RPDbB4agGK5Y68i3Pc3ibU=.3a32c67e-2bf4-4130-96f3-9e415b09ed93@github.com>

> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
> 
> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
> 
> * Testing
>   * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
>   * GHA

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28638/files
  - new: https://git.openjdk.org/jdk/pull/28638/files/f4707170..62d34e96

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

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

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

From shade at openjdk.org  Wed Dec  3 16:14:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Dec 2025 16:14:05 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
Message-ID: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>

On Wed, 3 Dec 2025 15:42:38 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>>  
>> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
>> - Disable coherent icache.
>> - Trap IC IVAU instructions.
>> - Execute:
>>    - `tlbi vae3is, xzr`
>>    - `dsb sy`
>>  
>>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>>  
>> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
>> 
>> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
>> 
>> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
>> 
>> Changes include:
>> 
>> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
>> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
>> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
>> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
>> 
>> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
>> 
>> - Baseline
>> 
>> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1...
>
> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Fix linux-cross-compile build aarch64
>  - Merge branch 'master' into JDK-8370947
>  - Remove trailing whitespaces
>  - Add support of deferred icache invalidation to other GCs and JIT
>  - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence
>  - Add jtreg test
>  - Fix linux-cross-compile aarch64 build
>  - Fix regressions for Java methods without field accesses
>  - Fix code style
>  - Correct ifdef; Add dsb after ic
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f

Interesting work! I was able to look through it very briefly:

src/hotspot/cpu/aarch64/globals_aarch64.hpp line 133:

> 131:           "Enable workaround for Neoverse N1 erratum 1542419")          \
> 132:   product(bool, UseDeferredICacheInvalidation, false, DIAGNOSTIC,       \
> 133:           "Defer multiple ICache invalidation to single invalidation")  \

Since the `ICacheInvalidationContext` is in shared code, and I suppose x86_64 would also benefit from this (at least eventually), this sounds like `globals.hpp` option.

src/hotspot/share/asm/codeBuffer.cpp line 371:

> 369:       !((oop_Relocation*)reloc)->oop_is_immediate()) {
> 370:     _has_non_immediate_oops = true;
> 371:   }

Honestly, this looks fragile? We can go into nmethods patching for some other reason, not for patching oops.

Also, we still might need to go and patch immediate oops? I see this:


  // Instruct loadConP of x86_64.ad places oops in code that are not also
  // listed in the oop section.
  static bool mustIterateImmediateOopsInCode() { return true; }


Is there a substantial loss is doing icache invalidation without checking for the existence of interesting oops? Do you have an idea how many methods this filters?

src/hotspot/share/asm/codeBuffer.cpp line 939:

> 937:     // Move all the code and relocations to the new blob:
> 938:     relocate_code_to(&cb);
> 939:   }

Here and later, the preferred style is:

Suggestion:

  // Move all the code and relocations to the new blob:
  {
    ICacheInvalidationContext icic(ICacheInvalidation::NOT_NEEDED);
    relocate_code_to(&cb);
  }

src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 37:

> 35: #include "memory/universe.hpp"
> 36: #include "runtime/atomicAccess.hpp"
> 37: #include "runtime/icache.hpp"

Include is added, but no actual use? Is something missing, or this is a leftover include?

test/hotspot/jtreg/gc/TestDeferredICacheInvalidation.java line 28:

> 26: 
> 27: /*
> 28:  * @test id=ParallelGC

Usually just:

Suggestion:

 * @test id=parallel

test/hotspot/jtreg/gc/TestDeferredICacheInvalidation.java line 34:

> 32:  * @requires vm.debug
> 33:  * @requires os.family=="linux"
> 34:  * @requires os.arch=="aarch64"

I am guessing it is more future-proof to drop Linux/AArch64 filters, and rely on test doing the right thing, regardless of the config. I see it already skips when `UseDeferredICacheInvalidation` is off.

test/micro/org/openjdk/bench/vm/gc/GCPatchingNmethodCost.java line 184:

> 182:     @Benchmark
> 183:     @Warmup(iterations = 0)
> 184:     @Measurement(iterations = 1)

Not sure what is the intent here. Maybe you wanted `@BenchmarkMode(OneShot)` instead?

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

PR Review: https://git.openjdk.org/jdk/pull/28328#pullrequestreview-3535752098
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585729392
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585679778
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585704068
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585707389
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585735476
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585734553
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585743873

From stefank at openjdk.org  Wed Dec  3 16:20:50 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Dec 2025 16:20:50 GMT
Subject: RFR: 8373025: Test:
 test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock [v2]
In-Reply-To: <Hu4Qz747lCADaygr7PSw-RPDbB4agGK5Y68i3Pc3ibU=.3a32c67e-2bf4-4130-96f3-9e415b09ed93@github.com>
References: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
 <Hu4Qz747lCADaygr7PSw-RPDbB4agGK5Y68i3Pc3ibU=.3a32c67e-2bf4-4130-96f3-9e415b09ed93@github.com>
Message-ID: <HCi6E4L7CvMD2eNIFx_l3dkYfKamQ5kH6DuWtUrfwaI=.4891afba-8bc9-4524-8679-03a3f5c6bf26@github.com>

On Wed, 3 Dec 2025 16:00:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
>> 
>> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
>> 
>> * Testing
>>   * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
>>   * GHA
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused variable

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28638#pullrequestreview-3535875087

From xpeng at openjdk.org  Wed Dec  3 16:23:29 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 16:23:29 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v3]
In-Reply-To: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
Message-ID: <s3NJoSpBGrnEHmL3G2J_nBJrv_2_Z7Gco7RpjrI4J9U=.458d9d07-c342-4820-b122-fa28d838548b@github.com>

> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
> 
> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
> 
> Test result:
> 
> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
> 
> With the change:
> 
> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
> 
> Original:
> 
> 
> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
> 
> 
> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 58% reduction for the time, 100%+ improvement for the performance/speed. 
> 
> ### Other tests
> - [x] hotspot_gc_shenandoah
> - [x] GHA

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Simplify comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28613/files
  - new: https://git.openjdk.org/jdk/pull/28613/files/3b964995..892676c5

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

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

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

From shade at openjdk.org  Wed Dec  3 16:23:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Dec 2025 16:23:30 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v3]
In-Reply-To: <s3NJoSpBGrnEHmL3G2J_nBJrv_2_Z7Gco7RpjrI4J9U=.458d9d07-c342-4820-b122-fa28d838548b@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <s3NJoSpBGrnEHmL3G2J_nBJrv_2_Z7Gco7RpjrI4J9U=.458d9d07-c342-4820-b122-fa28d838548b@github.com>
Message-ID: <qSDGcemJHC0L01o1u2vxLChf5sdHhExxmt6ZynRCY28=.578e8a56-f6a6-4aae-a54e-d826f15ec3a4@github.com>

On Wed, 3 Dec 2025 16:20:25 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
>> 
>> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
>> 
>> Test result:
>> 
>> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
>> 
>> With the change:
>> 
>> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
>> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
>> 
>> Original:
>> 
>> 
>> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
>> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
>> 
>> 
>> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 58% reduction for the time, 100%+ improvement for the performance/speed. 
>> 
>> ### Other tests
>> - [x] hotspot_gc_shenandoah
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify comments

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28613#pullrequestreview-3535887356

From xpeng at openjdk.org  Wed Dec  3 16:23:32 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 16:23:32 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v2]
In-Reply-To: <_UCh_KR6-uzVFOJ9MM-gK3gsTessZ03FuecOFkS2F8c=.86fbe32d-b450-4285-8906-ead7bd003b8f@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <vvZn1rp9Ys869R2epKPrVvaatOv8ADKR3alc_CaZxqg=.0a76a1c9-7ba3-487d-b326-c0db40cfd0e6@github.com>
 <_UCh_KR6-uzVFOJ9MM-gK3gsTessZ03FuecOFkS2F8c=.86fbe32d-b450-4285-8906-ead7bd003b8f@github.com>
Message-ID: <5mKXql8U-bSulRVIzoVQXqwcQXlm24-3xExvFAk5oYU=.0ddb4082-5d95-4c08-9c8a-125585d05af4@github.com>

On Wed, 3 Dec 2025 10:10:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add more comments.
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 88:
> 
>> 86:   // Using a smaller value here yields better task distribution for a lumpy workload. The task will be split
>> 87:   // into smaller batches with 8 regions in batch, the worker processes more regions w/o needs to reset bitmaps
>> 88:   // will process more batches, but overall all workers will be saturated throughout the whole concurrent reset phase.
> 
> I have a very general comment about writing comments like this one. This entire block of prose is really excessive, is set up to be outdated (are you tracking the real behavior of `SH::parallel_heap_region_iterate` and its magical `4096`?), and can be boiled down to much more succinct:
> 
> 
> Bitmap reset task is heavy-weight and benefits from much smaller tasks than the default.

Thanks a lot! I have updated the PR to use the succinct one you suggested.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 119:
> 
>> 117:   // ShenandoahHeap::parallel_heap_region_iterate will derive a reasonable value based
>> 118:   // on active worker threads and number of regions.
>> 119:   // For some lumpy workload, the value can be overridden for better task distribution.
> 
> Again, excessive. You can just drop the comment; its purpose is obvious from the code.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2585783241
PR Review Comment: https://git.openjdk.org/jdk/pull/28613#discussion_r2585784611

From duke at openjdk.org  Wed Dec  3 17:05:11 2025
From: duke at openjdk.org (duke)
Date: Wed, 3 Dec 2025 17:05:11 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder [v3]
In-Reply-To: <autgJQmEuJ3lQkJ1e_lATd5QU__3UEJ1uOZaoaew-8I=.70b8f1cf-9dd4-4254-9938-be5918949893@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
 <autgJQmEuJ3lQkJ1e_lATd5QU__3UEJ1uOZaoaew-8I=.70b8f1cf-9dd4-4254-9938-be5918949893@github.com>
Message-ID: <E8oGy17Ih3mGnbtOGVG8ErfYkyUApl6WxhtI8mI6YBg=.8a7d9641-5c0c-49bb-a1dd-3e5a53dbd7ca@github.com>

On Wed, 3 Dec 2025 14:38:57 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> 
>> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> 2. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected"). So, test is split into separate sections pertaining to GC requirements. @requires now has corresponding GC flag condition.
>> 3. Removal of WhiteBox dependency and few cleanups.
>> 
>> Testing:
>> HS Tiers 1 and 2 
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test split into sections

@rsunderbabu 
Your change (at version 3d1f32266bfcc245ff865ac62623dc44d74bf1f7) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28508#issuecomment-3607863823

From btaylor at openjdk.org  Wed Dec  3 17:26:19 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Wed, 3 Dec 2025 17:26:19 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
Message-ID: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>

The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.

A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566

This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build

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

Commit messages:
 - 8373039: Remove Incorrect Asserts in shenandoahScanRemembered

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

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

From wkemper at openjdk.org  Wed Dec  3 17:47:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Dec 2025 17:47:47 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
In-Reply-To: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
Message-ID: <k7x1xQfaVbeAwnJcybEqwippQGL_dEU6w9cy8gJmuYU=.dceda325-f236-493f-8875-66ee6b95d9e9@github.com>

On Wed, 3 Dec 2025 17:16:02 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.
> 
> A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566
> 
> This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build

Changes requested by wkemper (Reviewer).

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

> 382:   oop obj = cast_to_oop(p);
> 383:   assert(oopDesc::is_oop(obj), "Should be an object");
> 384:   assert(p <= left, "p should start at or before left end of card");

I think it's fine to take out this loop, but the assert on 384 now seems redundant to the assert on 363. I'm also not sure if the assert on 385 necessarily holds because `p` is no longer increased in the loop. Maybe remove this whole `#ifdef ASSERT` block, or leave in the loop and just take out the `Klass::is_valid` usage.

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

PR Review: https://git.openjdk.org/jdk/pull/28642#pullrequestreview-3536232605
PR Review Comment: https://git.openjdk.org/jdk/pull/28642#discussion_r2586068246

From ysr at openjdk.org  Wed Dec  3 18:30:29 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 3 Dec 2025 18:30:29 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
In-Reply-To: <k7x1xQfaVbeAwnJcybEqwippQGL_dEU6w9cy8gJmuYU=.dceda325-f236-493f-8875-66ee6b95d9e9@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
 <k7x1xQfaVbeAwnJcybEqwippQGL_dEU6w9cy8gJmuYU=.dceda325-f236-493f-8875-66ee6b95d9e9@github.com>
Message-ID: <yyVg7NXXyw60cNzzhLUA-IEfGhqy8ZVBaMXzLzh-eDc=.a77f5226-e45d-496a-9765-e8d8d890eb83@github.com>

On Wed, 3 Dec 2025 17:45:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.
>> 
>> A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566
>> 
>> This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 384:
> 
>> 382:   oop obj = cast_to_oop(p);
>> 383:   assert(oopDesc::is_oop(obj), "Should be an object");
>> 384:   assert(p <= left, "p should start at or before left end of card");
> 
> I think it's fine to take out this loop, but the assert on 384 now seems redundant to the assert on 363. I'm also not sure if the assert on 385 necessarily holds because `p` is no longer increased in the loop. Maybe remove this whole `#ifdef ASSERT` block, or leave in the loop and just take out the `Klass::is_valid` usage.

I agree. In addition, the comment should be updated so it doesn't make the confusing reference to "the loop that follows", which just went away, etc. It's fine to leave a suitably modified comment as to why it is safe to query the size of the object at the oop being returned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28642#discussion_r2586182968

From ysr at openjdk.org  Wed Dec  3 18:30:30 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 3 Dec 2025 18:30:30 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
In-Reply-To: <yyVg7NXXyw60cNzzhLUA-IEfGhqy8ZVBaMXzLzh-eDc=.a77f5226-e45d-496a-9765-e8d8d890eb83@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
 <k7x1xQfaVbeAwnJcybEqwippQGL_dEU6w9cy8gJmuYU=.dceda325-f236-493f-8875-66ee6b95d9e9@github.com>
 <yyVg7NXXyw60cNzzhLUA-IEfGhqy8ZVBaMXzLzh-eDc=.a77f5226-e45d-496a-9765-e8d8d890eb83@github.com>
Message-ID: <Aht9TIMSDn6G5HxzA-pF4OGEhyDsLCIxAgQTXKsLic0=.7b1ddab5-addb-464e-9808-9b7003aef8e3@github.com>

On Wed, 3 Dec 2025 18:24:58 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 384:
>> 
>>> 382:   oop obj = cast_to_oop(p);
>>> 383:   assert(oopDesc::is_oop(obj), "Should be an object");
>>> 384:   assert(p <= left, "p should start at or before left end of card");
>> 
>> I think it's fine to take out this loop, but the assert on 384 now seems redundant to the assert on 363. I'm also not sure if the assert on 385 necessarily holds because `p` is no longer increased in the loop. Maybe remove this whole `#ifdef ASSERT` block, or leave in the loop and just take out the `Klass::is_valid` usage.
>
> I agree. In addition, the comment should be updated so it doesn't make the confusing reference to "the loop that follows", which just went away, etc. It's fine to leave a suitably modified comment as to why it is safe to query the size of the object at the oop being returned.

> I'm also not sure if the assert on 385 necessarily holds because p is no longer increased in the loop.

It should hold for the oop/object being returned here. It's a post-condition of the method which should have been stated in its API spec I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28642#discussion_r2586190041

From aboldtch at openjdk.org  Wed Dec  3 18:37:44 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Dec 2025 18:37:44 GMT
Subject: RFR: 8373025: Test:
 test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock [v3]
In-Reply-To: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
References: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
Message-ID: <9zSX9cB_iSIS1DcYhh4X0fQMg_0LxhzrFpEdVh73tPA=.b29ee8ec-3cbf-496c-a6d9-4d56831c75f1@github.com>

> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
> 
> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
> 
> * Testing
>   * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
>   * GHA

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

 - Remove problem-listing
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8373025
 - Need to support windows as well
 - Remove unused variable
 - Fix the comment
 - 8373025: Test: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28638/files
  - new: https://git.openjdk.org/jdk/pull/28638/files/62d34e96..672b746e

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

  Stats: 1699 lines in 51 files changed: 1321 ins; 166 del; 212 mod
  Patch: https://git.openjdk.org/jdk/pull/28638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28638/head:pull/28638

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

From eastigeevich at openjdk.org  Wed Dec  3 18:48:32 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 18:48:32 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <TNyOayj-ljQFUNklcFWFkLkCAk0Rz445UnWVYw98SLE=.f8d83ee3-71d7-4011-bcab-87abf47ed9eb@github.com>

On Wed, 3 Dec 2025 16:10:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - Fix linux-cross-compile build aarch64
>>  - Merge branch 'master' into JDK-8370947
>>  - Remove trailing whitespaces
>>  - Add support of deferred icache invalidation to other GCs and JIT
>>  - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence
>>  - Add jtreg test
>>  - Fix linux-cross-compile aarch64 build
>>  - Fix regressions for Java methods without field accesses
>>  - Fix code style
>>  - Correct ifdef; Add dsb after ic
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f
>
> test/micro/org/openjdk/bench/vm/gc/GCPatchingNmethodCost.java line 184:
> 
>> 182:     @Benchmark
>> 183:     @Warmup(iterations = 0)
>> 184:     @Measurement(iterations = 1)
> 
> Not sure what is the intent here. Maybe you wanted `@BenchmarkMode(OneShot)` instead?

The current algorithm:
- Create an object used in Java methods.
- Run the methods in the interpreter.
- Compile the methods.
- Make the object garbage collectable.
- Run GC (we measure this).

There are not many things to warm-up. And setting up everything for multiple iterations of GC runs might be expensive. Instead we use forks.

IMO, Yes it is `@BenchmarkMode(OneShot)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2586236955

From eastigeevich at openjdk.org  Wed Dec  3 18:53:10 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 18:53:10 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <W5TcIjBx38SKka6sgFJbenaWPf4oFsex7UanJdj4zio=.d4f77822-8065-4a2f-8f78-e42f17942f24@github.com>

On Wed, 3 Dec 2025 16:00:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - Fix linux-cross-compile build aarch64
>>  - Merge branch 'master' into JDK-8370947
>>  - Remove trailing whitespaces
>>  - Add support of deferred icache invalidation to other GCs and JIT
>>  - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence
>>  - Add jtreg test
>>  - Fix linux-cross-compile aarch64 build
>>  - Fix regressions for Java methods without field accesses
>>  - Fix code style
>>  - Correct ifdef; Add dsb after ic
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f
>
> src/hotspot/share/asm/codeBuffer.cpp line 939:
> 
>> 937:     // Move all the code and relocations to the new blob:
>> 938:     relocate_code_to(&cb);
>> 939:   }
> 
> Here and later, the preferred style is:
> 
> Suggestion:
> 
>   // Move all the code and relocations to the new blob:
>   {
>     ICacheInvalidationContext icic(ICacheInvalidation::NOT_NEEDED);
>     relocate_code_to(&cb);
>   }

I followed @xmas92 comments on style to use a blank line. @xmas92, what style should I follow?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2586248135

From shade at openjdk.org  Wed Dec  3 18:53:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Dec 2025 18:53:13 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <TNyOayj-ljQFUNklcFWFkLkCAk0Rz445UnWVYw98SLE=.f8d83ee3-71d7-4011-bcab-87abf47ed9eb@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
 <TNyOayj-ljQFUNklcFWFkLkCAk0Rz445UnWVYw98SLE=.f8d83ee3-71d7-4011-bcab-87abf47ed9eb@github.com>
Message-ID: <q-Cu3xNrUYcTgpyEF_qQu_avHDvO9oSXi35vcEFJvko=.6b4baa37-f143-45b0-8e89-f5f560f5c8ae@github.com>

On Wed, 3 Dec 2025 18:45:25 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/vm/gc/GCPatchingNmethodCost.java line 184:
>> 
>>> 182:     @Benchmark
>>> 183:     @Warmup(iterations = 0)
>>> 184:     @Measurement(iterations = 1)
>> 
>> Not sure what is the intent here. Maybe you wanted `@BenchmarkMode(OneShot)` instead?
>
> The current algorithm:
> - Create an object used in Java methods.
> - Run the methods in the interpreter.
> - Compile the methods.
> - Make the object garbage collectable.
> - Run GC (we measure this).
> 
> There are not many things to warm-up. And setting up everything for multiple iterations of GC runs might be expensive. Instead we use forks.
> 
> IMO, Yes it is `@BenchmarkMode(OneShot)`.

Yeah, but first GC would likely be slower, because it would have more real work to do. So you probably want OneShot with the default number of iterations. It will warmup by doing a few GCs, and then do a few other GCs for measurement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2586250541

From wkemper at openjdk.org  Wed Dec  3 18:56:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Dec 2025 18:56:56 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect
In-Reply-To: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
Message-ID: <DUWXfMCOfHqtZS88oDOZl1o-HUk1uQlPgePRq0SmScM=.d9fb25f4-7a40-4367-8af4-dd366edf76ba@github.com>

On Wed, 3 Dec 2025 02:02:18 GMT, Rui Li <duke at openjdk.org> wrote:

> Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 
> 
> Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:
> 
> 
> available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
> soft_tail = Xmx - soft_max
> if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 
> 
> 
> The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.
> 
> 
> Suggested fix: when deciding when to trigger gc, use logic similar to below:
> 
> mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
> available = mutator_soft_capacity - used;
> if (available < mutator_soft_capacity) // trigger gc
> ``` 
> 
> -------
> This change also improved gc logging:
> 
> Before:
> 
> [6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
> [6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
> external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B
> 
> 
> After:
> 
> [8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
> [8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
> 1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
> 1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
> 122, Reserved: 102M, Max free available in a single region: 1024K;

A few nits. Thank you for adding a test case for this!

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 240:

> 238:   size_t allocated = _space_info->bytes_allocated_since_gc_start();
> 239: 
> 240:   log_debug(gc)("should_start_gc calculation: available: %zu%s, soft_max_capacity: %zu%s"

Can we add `ergo` tag to this message? Let's use the `PROPERFMT` and `PROPERFMTARGS` macros here and in other log messages we're changing.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 258:

> 256:   size_t min_threshold = min_free_threshold();
> 257:   if (available < min_threshold) {
> 258:     log_trigger("Free (Soft mutator free) (%zu%s) is below minimum threshold (%zu%s)",

Changing this will break some log parsers, do we really need this?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp line 52:

> 50:   size_t capacity = ShenandoahHeap::heap()->soft_max_capacity();
> 51:   size_t available = _space_info->soft_available();
> 52:   size_t allocated = _space_info->bytes_allocated_since_gc_start();

This shadows `bytes_allocated` below. Let's just use one variable for this.

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

> 3207:     log_freeset_stats(ShenandoahFreeSetPartitionId::Mutator, ls);
> 3208:     log_freeset_stats(ShenandoahFreeSetPartitionId::Collector, ls);
> 3209:     if (_heap->mode()->is_generational()) {log_freeset_stats(ShenandoahFreeSetPartitionId::OldCollector, ls);}

Suggestion:

    if (_heap->mode()->is_generational()) {
      log_freeset_stats(ShenandoahFreeSetPartitionId::OldCollector, ls);
    }

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 632:

> 630:   size_t get_usable_free_words(size_t free_bytes) const;
> 631: 
> 632:   void log_freeset_stats(ShenandoahFreeSetPartitionId partition_id, LogStream& ls);

`log_freeset_stats` should probably be `private`.

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28622#pullrequestreview-3536428634
PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2586232667
PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2586234993
PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2586237553
PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2586243946
PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2586247150

From ayang at openjdk.org  Wed Dec  3 19:35:08 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 3 Dec 2025 19:35:08 GMT
Subject: RFR: 8373025: Test:
 test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock [v3]
In-Reply-To: <9zSX9cB_iSIS1DcYhh4X0fQMg_0LxhzrFpEdVh73tPA=.b29ee8ec-3cbf-496c-a6d9-4d56831c75f1@github.com>
References: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
 <9zSX9cB_iSIS1DcYhh4X0fQMg_0LxhzrFpEdVh73tPA=.b29ee8ec-3cbf-496c-a6d9-4d56831c75f1@github.com>
Message-ID: <rTtwVMbRPnpe6I8LSNXqk4NuRV8DZOZSm2OMPksbhSU=.049ee89b-dbf7-4405-b504-d3b536684b71@github.com>

On Wed, 3 Dec 2025 18:37:44 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
>> 
>> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
>> 
>> * Testing
>>   * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
>>   * GHA
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Remove problem-listing
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8373025
>  - Need to support windows as well
>  - Remove unused variable
>  - Fix the comment
>  - 8373025: Test: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28638#pullrequestreview-3536609789

From eastigeevich at openjdk.org  Wed Dec  3 19:51:32 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 19:51:32 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <q-Cu3xNrUYcTgpyEF_qQu_avHDvO9oSXi35vcEFJvko=.6b4baa37-f143-45b0-8e89-f5f560f5c8ae@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
 <TNyOayj-ljQFUNklcFWFkLkCAk0Rz445UnWVYw98SLE=.f8d83ee3-71d7-4011-bcab-87abf47ed9eb@github.com>
 <q-Cu3xNrUYcTgpyEF_qQu_avHDvO9oSXi35vcEFJvko=.6b4baa37-f143-45b0-8e89-f5f560f5c8ae@github.com>
Message-ID: <eXswBzRDVTunuOvsneav_TJ_HdU_M4xRp4lzYWmgjIs=.df5bc49c-1342-47d1-8016-9f2b9399b4a5@github.com>

On Wed, 3 Dec 2025 18:50:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The current algorithm:
>> - Create an object used in Java methods.
>> - Run the methods in the interpreter.
>> - Compile the methods.
>> - Make the object garbage collectable.
>> - Run GC (we measure this).
>> 
>> There are not many things to warm-up. And setting up everything for multiple iterations of GC runs might be expensive. Instead we use forks.
>> 
>> IMO, Yes it is `@BenchmarkMode(OneShot)`.
>
> Yeah, but first GC would likely be slower, because it would have more real work to do. So you probably want OneShot with the default number of iterations. It will warmup by doing a few GCs, and then do a few other GCs for measurement.

I have `Thread.sleep(1000)` in `setupCodeCache()` to let everything to settle down. I use it because I saw high variance in GC times. With it variance became OK.

Maybe I should use `System.gc()` instead of `Thread.sleep`.

> So you probably want OneShot with the default number of iterations.

Will I need to recreate an object and to rerun Java methods before each iteration? The first iteration will collect garbage object `fields`. So following iterations running GC will do nothing. Or will they patch nmethods again?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2586405992

From xpeng at openjdk.org  Wed Dec  3 21:18:42 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 21:18:42 GMT
Subject: RFR: 8373048: Genshen: Remove dead code from Shenandoah
Message-ID: <cgZkXy2-7YVtGODIZ7m34Wemyx_enDgmSbubxipxZ0k=.44a2e2dd-2d5f-4931-b7bb-46ed8ef453b4@github.com>

Trivial PR to remove dead code from Shenandoah. I noticed some dead code in shenandoahFreeSet.cpp when I was working on https://github.com/openjdk/jdk/pull/26171, this PR is to clean up the dead code in shenandoahFreeSet.cpp and some other files, no functional change at all.

### Test
- [x] hotspot_gc_shenandoah
- [ ] GHA

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

Commit messages:
 - Removed dead code

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

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

From wkemper at openjdk.org  Wed Dec  3 21:28:24 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Dec 2025 21:28:24 GMT
Subject: RFR: 8373048: Genshen: Remove dead code from Shenandoah
In-Reply-To: <cgZkXy2-7YVtGODIZ7m34Wemyx_enDgmSbubxipxZ0k=.44a2e2dd-2d5f-4931-b7bb-46ed8ef453b4@github.com>
References: <cgZkXy2-7YVtGODIZ7m34Wemyx_enDgmSbubxipxZ0k=.44a2e2dd-2d5f-4931-b7bb-46ed8ef453b4@github.com>
Message-ID: <q7d_CMZCzDZCQ2piOVnkDV3d8QjKU4RaAFpPt50Za2Q=.7d357770-aa89-4a56-a32c-d5ee4b18a45e@github.com>

On Wed, 3 Dec 2025 20:55:09 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Trivial PR to remove dead code from Shenandoah. I noticed some dead code in shenandoahFreeSet.cpp when I was working on https://github.com/openjdk/jdk/pull/26171, this PR is to clean up the dead code in shenandoahFreeSet.cpp and some other files, no functional change at all.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [ ] GHA

Nice cleanup, thank you!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28647#pullrequestreview-3536983896

From kdnilsen at openjdk.org  Wed Dec  3 21:33:59 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 3 Dec 2025 21:33:59 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v3]
In-Reply-To: <s3NJoSpBGrnEHmL3G2J_nBJrv_2_Z7Gco7RpjrI4J9U=.458d9d07-c342-4820-b122-fa28d838548b@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <s3NJoSpBGrnEHmL3G2J_nBJrv_2_Z7Gco7RpjrI4J9U=.458d9d07-c342-4820-b122-fa28d838548b@github.com>
Message-ID: <IOswPZNoGhfZa7IoxhPPIS_1op6RgsNN9-A6E53VR4g=.8c9448ab-3f92-4082-a89d-00a84f1ae921@github.com>

On Wed, 3 Dec 2025 16:23:29 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
>> 
>> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
>> 
>> Test result:
>> 
>> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
>> 
>> With the change:
>> 
>> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
>> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
>> 
>> Original:
>> 
>> 
>> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
>> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
>> 
>> 
>> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 58% reduction for the time, 100%+ improvement for the performance/speed. 
>> 
>> ### Other tests
>> - [x] hotspot_gc_shenandoah
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify comments

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28613#pullrequestreview-3537003493

From btaylor at openjdk.org  Wed Dec  3 21:42:55 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Wed, 3 Dec 2025 21:42:55 GMT
Subject: RFR: 8373054: Shenandoah: Remove unnecessary BarrierSetNMethod::arm in
 shenandoahCodeRoots
Message-ID: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>

The call to arm is redundant, and can be replaced with an assert to ensure the precondition remains true.

The same set of tier1 tests pass before and after this change with a fastdebug and Shenandoah GC.

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

Commit messages:
 - 8373054: Shenandoah: Remove unnecessary BarrierSetNMethod::arm in shenandoahCodeRoots

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

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

From wkemper at openjdk.org  Wed Dec  3 21:42:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Dec 2025 21:42:56 GMT
Subject: RFR: 8373054: Shenandoah: Remove unnecessary
 BarrierSetNMethod::arm in shenandoahCodeRoots
In-Reply-To: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
References: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
Message-ID: <MioIuSpwKlOCCTZAiF-5iOOb9PPrrh9HaLDbIMcVYoY=.fd804607-6acf-42de-b681-e9e75d473e87@github.com>

On Wed, 3 Dec 2025 21:33:50 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The call to arm is redundant, and can be replaced with an assert to ensure the precondition remains true.
> 
> The same set of tier1 tests pass before and after this change with a fastdebug and Shenandoah GC.

Let's change the misleading comment.

src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 147:

> 145:       ShenandoahReentrantLocker locker(nm_data->lock());
> 146: 
> 147:       // Heal oops and disarm

Suggestion:

      // Heal oops and leave the nmethod armed because code cache unloading needs to know about on-stack nmethods.

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28648#pullrequestreview-3537029053
PR Review Comment: https://git.openjdk.org/jdk/pull/28648#discussion_r2586693272

From btaylor at openjdk.org  Wed Dec  3 22:07:15 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Wed, 3 Dec 2025 22:07:15 GMT
Subject: RFR: 8373054: Shenandoah: Remove unnecessary
 BarrierSetNMethod::arm in shenandoahCodeRoots [v2]
In-Reply-To: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
References: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
Message-ID: <X2WC7PonMkLuEs08wOA8N0U6aiLnOdqq6BJHlJlR7Y0=.2186a96e-1b29-41fd-95f5-77d943134b6b@github.com>

> The call to arm is redundant, and can be replaced with an assert to ensure the precondition remains true.
> 
> The same set of tier1 tests pass before and after this change with a fastdebug and Shenandoah GC.

Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:

  Fix misleading comment in previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28648/files
  - new: https://git.openjdk.org/jdk/pull/28648/files/d830a0a1..a1a9bf11

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

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

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

From btaylor at openjdk.org  Wed Dec  3 22:08:11 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Wed, 3 Dec 2025 22:08:11 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
 [v2]
In-Reply-To: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
Message-ID: <zXMdo0vjaMhDeoe087_RtjFiFiPEQONUuCKb0rk6tY8=.5dd40b40-52b8-4d58-8616-30765125ea47@github.com>

> The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.
> 
> A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566
> 
> This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build

Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:

  Fix up comment and remove additional assert from previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28642/files
  - new: https://git.openjdk.org/jdk/pull/28642/files/03456d6f..eec662f6

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

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

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

From xpeng at openjdk.org  Wed Dec  3 22:45:02 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 22:45:02 GMT
Subject: RFR: 8373048: Genshen: Remove dead code from Shenandoah
In-Reply-To: <cgZkXy2-7YVtGODIZ7m34Wemyx_enDgmSbubxipxZ0k=.44a2e2dd-2d5f-4931-b7bb-46ed8ef453b4@github.com>
References: <cgZkXy2-7YVtGODIZ7m34Wemyx_enDgmSbubxipxZ0k=.44a2e2dd-2d5f-4931-b7bb-46ed8ef453b4@github.com>
Message-ID: <IMJRtYnusimb9gvkvCwNTSllupmbi1q1lq7txvqV1Y4=.5020cd38-2833-49da-ae3d-a59c3b8cf2a5@github.com>

On Wed, 3 Dec 2025 20:55:09 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Trivial PR to remove dead code from Shenandoah. I noticed some dead code in shenandoahFreeSet.cpp when I was working on https://github.com/openjdk/jdk/pull/26171, this PR is to clean up the dead code in shenandoahFreeSet.cpp and some other files, no functional change at all.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] GHA

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/28647#issuecomment-3609153899

From xpeng at openjdk.org  Wed Dec  3 22:46:14 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 22:46:14 GMT
Subject: RFR: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism [v3]
In-Reply-To: <s3NJoSpBGrnEHmL3G2J_nBJrv_2_Z7Gco7RpjrI4J9U=.458d9d07-c342-4820-b122-fa28d838548b@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
 <s3NJoSpBGrnEHmL3G2J_nBJrv_2_Z7Gco7RpjrI4J9U=.458d9d07-c342-4820-b122-fa28d838548b@github.com>
Message-ID: <J4xRuLiZib_Oakb0FadY61B_l_rPyj1tVxWUXAWudUE=.f8c0844a-1ecd-4688-8c1b-0eaf82a24b05@github.com>

On Wed, 3 Dec 2025 16:23:29 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
>> 
>> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
>> 
>> Test result:
>> 
>> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
>> 
>> With the change:
>> 
>> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
>> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
>> 
>> Original:
>> 
>> 
>> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
>> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
>> 
>> 
>> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 58% reduction for the time, 100%+ improvement for the performance/speed. 
>> 
>> ### Other tests
>> - [x] hotspot_gc_shenandoah
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify comments

Thanks all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28613#issuecomment-3609152280

From xpeng at openjdk.org  Wed Dec  3 22:46:16 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 22:46:16 GMT
Subject: Integrated: 8372861: Genshen: Override parallel_region_stride of
 ShenandoahResetBitmapClosure to a reasonable value for better parallelism
In-Reply-To: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
References: <6uz-mrC1sU0Q8kxBHKCDFLarpR2mNERthlu_w8s0ym4=.00d5486d-1704-4484-8339-a081f68f8793@github.com>
Message-ID: <xS2njRWTZacpHhl94c37TCZh5hHg0tY3iOarRXwdjT0=.ed399738-d3d1-4a6f-94a6-247cda8312bd@github.com>

On Tue, 2 Dec 2025 18:59:25 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In concurrent reset/concurrent reset after collect phase, the worker needs to reset bitmaps for all the regions in current GC generation. The problem is resetting bitmaps may takes long for large heap because the marking bitmaps are also larger than small heap, we should always consider multiple threads if there are more than concurrent workers for concurrent reset. 
> 
> In this PR, parallel_region_stride for ShenandoahResetBitmapClosure is set to 8 for best possible workload distribution to all active workers.
> 
> Test result:
> 
> java -XX:+TieredCompilation -XX:+AlwaysPreTouch -Xms32G -Xmx32G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -Xlog:gc* -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/Downloads/dacapo-23.11-MR2-chopin.jar -n 5 h2 | grep "Concurrent Reset"
> 
> With the change:
> 
> [77.867s][info][gc,stats    ] Concurrent Reset               =    0.043 s (a =     3039 us) (n =    14) (lvls, us =     1133,     1230,     1270,     1328,    14650)
> [77.867s][info][gc,stats    ] Concurrent Reset After Collect =    0.043 s (a =     3107 us) (n =    14) (lvls, us =     1094,     1230,     1855,     3457,     8348)
> 
> Original:
> 
> 
> [77.289s][info][gc,stats    ] Concurrent Reset               =    0.045 s (a =     3197 us) (n =    14) (lvls, us =     1172,     1191,     1309,     1426,    15582)
> [77.289s][info][gc,stats    ] Concurrent Reset After Collect =    0.105 s (a =     7476 us) (n =    14) (lvls, us =     2246,     3828,     4395,     7695,    21266)
> 
> 
> The average time of concurrent reset after collect is reduced from 7476 us to 3107 us, 58% reduction for the time, 100%+ improvement for the performance/speed. 
> 
> ### Other tests
> - [x] hotspot_gc_shenandoah
> - [x] GHA

This pull request has now been integrated.

Changeset: db2a5420
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db2a5420a2e3d0f5f0f066eace37a8fd4f075802
Stats:     13 lines in 4 files changed: 12 ins; 0 del; 1 mod

8372861: Genshen: Override parallel_region_stride of ShenandoahResetBitmapClosure to a reasonable value for better parallelism

Reviewed-by: kdnilsen, shade, wkemper

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

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

From xpeng at openjdk.org  Wed Dec  3 22:49:07 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 22:49:07 GMT
Subject: Integrated: 8373048: Genshen: Remove dead code from Shenandoah
In-Reply-To: <cgZkXy2-7YVtGODIZ7m34Wemyx_enDgmSbubxipxZ0k=.44a2e2dd-2d5f-4931-b7bb-46ed8ef453b4@github.com>
References: <cgZkXy2-7YVtGODIZ7m34Wemyx_enDgmSbubxipxZ0k=.44a2e2dd-2d5f-4931-b7bb-46ed8ef453b4@github.com>
Message-ID: <7zQpw05McTnnh2XNSZ4jc1FIMOcGiKUObOM-_sZhAfo=.1a091412-513e-4018-97c0-62cd4b004016@github.com>

On Wed, 3 Dec 2025 20:55:09 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Trivial PR to remove dead code from Shenandoah. I noticed some dead code in shenandoahFreeSet.cpp when I was working on https://github.com/openjdk/jdk/pull/26171, this PR is to clean up the dead code in shenandoahFreeSet.cpp and some other files, no functional change at all.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] GHA

This pull request has now been integrated.

Changeset: 8f8fda7c
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f8fda7c80b57e8a36827cc260f0be0e5d61f6a6
Stats:     145 lines in 7 files changed: 0 ins; 143 del; 2 mod

8373048: Genshen: Remove dead code from Shenandoah

Reviewed-by: wkemper

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

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

From duke at openjdk.org  Wed Dec  3 22:50:49 2025
From: duke at openjdk.org (Rui Li)
Date: Wed, 3 Dec 2025 22:50:49 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect
In-Reply-To: <DUWXfMCOfHqtZS88oDOZl1o-HUk1uQlPgePRq0SmScM=.d9fb25f4-7a40-4367-8af4-dd366edf76ba@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
 <DUWXfMCOfHqtZS88oDOZl1o-HUk1uQlPgePRq0SmScM=.d9fb25f4-7a40-4367-8af4-dd366edf76ba@github.com>
Message-ID: <cWLnVbzR3O6vup7fhlfGAdhE7_860iHHnGTicWXEbqA=.b5f8c31e-dcaf-41aa-9c3c-7a7222ccf205@github.com>

On Wed, 3 Dec 2025 18:43:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 
>> 
>> Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:
>> 
>> 
>> available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
>> soft_tail = Xmx - soft_max
>> if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 
>> 
>> 
>> The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.
>> 
>> 
>> Suggested fix: when deciding when to trigger gc, use logic similar to below:
>> 
>> mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
>> available = mutator_soft_capacity - used;
>> if (available < mutator_soft_capacity) // trigger gc
>> ``` 
>> 
>> -------
>> This change also improved gc logging:
>> 
>> Before:
>> 
>> [6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
>> [6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
>> external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B
>> 
>> 
>> After:
>> 
>> [8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
>> [8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
>> 1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
>> 1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
>> 122, Reserved: 102M, Max free available in a single region: 1024K;
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 240:
> 
>> 238:   size_t allocated = _space_info->bytes_allocated_since_gc_start();
>> 239: 
>> 240:   log_debug(gc)("should_start_gc calculation: available: %zu%s, soft_max_capacity: %zu%s"
> 
> Can we add `ergo` tag to this message? Let's use the `PROPERFMT` and `PROPERFMTARGS` macros here and in other log messages we're changing.

Sure.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp line 52:
> 
>> 50:   size_t capacity = ShenandoahHeap::heap()->soft_max_capacity();
>> 51:   size_t available = _space_info->soft_available();
>> 52:   size_t allocated = _space_info->bytes_allocated_since_gc_start();
> 
> This shadows `bytes_allocated` below. Let's just use one variable for this.

Good catch. Removed one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2586856567
PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2586856298

From xpeng at openjdk.org  Wed Dec  3 23:24:29 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 23:24:29 GMT
Subject: RFR: 8373056: Shenandoah: Remove unnecessary use of
 ShenandoahAllocRequest.type()
Message-ID: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>

Follow up on the feedback/comments on PR https://github.com/openjdk/jdk/pull/28521 for bug [JDK-8372566](https://bugs.openjdk.org/browse/JDK-8372566), we should avoid using ShenandoahAllocRequest.type() directly if possible, in most of cases we don't need to directly alloc type, the inline member methods provided by ShenandoahAllocRequest should be sufficient.

In the PR, I have removed most of the places where ShenandoahAllocRequest.type() directly used, there will be only one place left after the change:
* ShenandoahFreeSet::allocate (This one will be removed with PR https://github.com/openjdk/jdk/pull/26171)

Also did small code rearrangement for ShenandoahOldGeneration::configure_plab_for_current_thread 

### Test
- [ ] hotspot_gc_shenandoah
- [ ] GHA

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

Commit messages:
 - Remove direct use of alloc type from ShenandoahHeapRegion::adjust_alloc_metadata
 - Revert log change
 - Remove unnecessary use of ShenandoahAllocRequest.type()

Changes: https://git.openjdk.org/jdk/pull/28649/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373056
  Stats: 79 lines in 6 files changed: 12 ins; 20 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/28649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28649/head:pull/28649

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

From duke at openjdk.org  Wed Dec  3 23:26:56 2025
From: duke at openjdk.org (Rui Li)
Date: Wed, 3 Dec 2025 23:26:56 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect
In-Reply-To: <DUWXfMCOfHqtZS88oDOZl1o-HUk1uQlPgePRq0SmScM=.d9fb25f4-7a40-4367-8af4-dd366edf76ba@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
 <DUWXfMCOfHqtZS88oDOZl1o-HUk1uQlPgePRq0SmScM=.d9fb25f4-7a40-4367-8af4-dd366edf76ba@github.com>
Message-ID: <ivlDtlaMTe57hSHPChMfHGki2EbfaKpnE3oRz_KZiFU=.a7174316-465a-4512-b5c7-85431fe91d44@github.com>

On Wed, 3 Dec 2025 18:49:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 
>> 
>> Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:
>> 
>> 
>> available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
>> soft_tail = Xmx - soft_max
>> if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 
>> 
>> 
>> The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.
>> 
>> 
>> Suggested fix: when deciding when to trigger gc, use logic similar to below:
>> 
>> mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
>> available = mutator_soft_capacity - used;
>> if (available < mutator_soft_capacity) // trigger gc
>> ``` 
>> 
>> -------
>> This change also improved gc logging:
>> 
>> Before:
>> 
>> [6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
>> [6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
>> external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B
>> 
>> 
>> After:
>> 
>> [8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
>> [8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
>> 1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
>> 1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
>> 122, Reserved: 102M, Max free available in a single region: 1024K;
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 632:
> 
>> 630:   size_t get_usable_free_words(size_t free_bytes) const;
>> 631: 
>> 632:   void log_freeset_stats(ShenandoahFreeSetPartitionId partition_id, LogStream& ls);
> 
> `log_freeset_stats` should probably be `private`.

I thought it was private already? The `private` starts from [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp#L478). Or, if you expand this section a bit to line 636, another `public` starts after these declaration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2586918976

From xpeng at openjdk.org  Wed Dec  3 23:30:21 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 23:30:21 GMT
Subject: RFR: 8373056: Shenandoah: Remove unnecessary use of
 ShenandoahAllocRequest.type() [v2]
In-Reply-To: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
References: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
Message-ID: <1wB8K5uAm9h-sVDOlHskuhpH_kNuJIcxhBTHrkfDck0=.07cd6bd4-5cc5-4ec6-afbb-bb4b9cfa1cde@github.com>

> Follow up on the feedback/comments on PR https://github.com/openjdk/jdk/pull/28521 for bug [JDK-8372566](https://bugs.openjdk.org/browse/JDK-8372566), we should avoid using ShenandoahAllocRequest.type() directly if possible, in most of cases we don't need to directly use alloc type, the inline member methods provided by ShenandoahAllocRequest should be sufficient.
> 
> In the PR, I have removed most of the places where ShenandoahAllocRequest.type() directly used, there will be only one place left after the change:
> * ShenandoahFreeSet::allocate (This one will be removed with PR https://github.com/openjdk/jdk/pull/26171)
> 
> Also did small code rearrangement for ShenandoahOldGeneration::configure_plab_for_current_thread 
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [ ] GHA

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

 - Merge branch 'openjdk:master' into JDK-8373056
 - Remove direct use of alloc type from ShenandoahHeapRegion::adjust_alloc_metadata
 - Revert log change
 - Remove unnecessary use of ShenandoahAllocRequest.type()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28649/files
  - new: https://git.openjdk.org/jdk/pull/28649/files/28f802d8..59087c8e

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

  Stats: 9796 lines in 279 files changed: 6048 ins; 2286 del; 1462 mod
  Patch: https://git.openjdk.org/jdk/pull/28649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28649/head:pull/28649

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

From eastigeevich at openjdk.org  Wed Dec  3 23:36:03 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 23:36:03 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <z1ruHGM9HHIcv4BSrkuS_RTo64sLga_AjXBnk6jOriw=.0f2f95aa-869d-4183-92f6-83f3415a0e02@github.com>

On Wed, 3 Dec 2025 15:54:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Honestly, this looks fragile? We can go into nmethods patching for some other reason, not for patching oops.

For GCs on ARM64, I found only patching `nmethod::fix_oop_relocations` and patching ZGC barriers. This may be because `mustIterateImmediateOopsInCode` return false on ARM64. We will need to add support of instructions modified through `OopClosure::do_oop`.

> Is there a substantial loss is doing icache invalidation without checking for the existence of interesting oops? Do you have an idea how many methods this filters?

https://github.com/openjdk/jdk/pull/28328#issuecomment-3558673810

Axel (@xmas92) saw some SpecJVM regressions. I think they might be caused by the increased number of icache invalidation. We had not patched methods, no icache invalidation, before this PR and started always-icache invalidation after this PR. I will be checking SpecJVM, SpecJBB and other benchmarks (dacapo, renaissance).

I might check if the following approach does not have much overhead:
- In `nmethod::fix_oop_relocations`

ICacheInvalidationContext icic(UseDeferredICacheInvalidation : ICacheInvalidation::DEFERRED ? ICacheInvalidation::IMMEDIATE);
bool patching_code = false;
while (iter.next()) {
...
patching_code = reloc->fix_oop_relocation();
...
patching_code = reloc->fix_metadata_relocation();
}
If (icic.mode() ==  ICacheInvalidation::DEFERRED && !patching_code) {
  icic.set_mode(ICacheInvalidation::NOT_NEEDED);
}


If it works, it will reduce amount of changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2586934914

From xpeng at openjdk.org  Wed Dec  3 23:41:26 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 3 Dec 2025 23:41:26 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v15]
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <MK03CFjwnPY_QCAtEAOAnHJI3HpYyOiFSC6vAuoAHUo=.9aada189-4954-4bcf-9e7f-37b1ab5cf9c6@github.com>

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code:
> 
> * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class.
> * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and  `_yield_to_safepoint` to customize the allocator for mutator.
> * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. 
> * ShenandoahOldCollectorAllocator:  allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector`
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. 
> 
> java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> 
> 
> Openjdk TIP:
> 
> ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 2...

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 256 commits:

 - Merge branch 'openjdk:master' into cas-alloc-1
 - Add missing header for ShenandoahFreeSetPartitionId
 - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
 - Fix a typo
 - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
 - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
 - Port the fix of JDK-8372566
 - Merge branch 'master' into cas-alloc-1
 - Merge remote-tracking branch 'origin/master' into cas-alloc-1
 - Remove junk code
 - ... and 246 more: https://git.openjdk.org/jdk/compare/8f8fda7c...f9f74ff0

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

Changes: https://git.openjdk.org/jdk/pull/26171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=14
  Stats: 1637 lines in 25 files changed: 1283 ins; 242 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

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

From wkemper at openjdk.org  Wed Dec  3 23:51:59 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Dec 2025 23:51:59 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect
In-Reply-To: <ivlDtlaMTe57hSHPChMfHGki2EbfaKpnE3oRz_KZiFU=.a7174316-465a-4512-b5c7-85431fe91d44@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
 <DUWXfMCOfHqtZS88oDOZl1o-HUk1uQlPgePRq0SmScM=.d9fb25f4-7a40-4367-8af4-dd366edf76ba@github.com>
 <ivlDtlaMTe57hSHPChMfHGki2EbfaKpnE3oRz_KZiFU=.a7174316-465a-4512-b5c7-85431fe91d44@github.com>
Message-ID: <kuJi02z6ky0yGD0sXkF0AXmn_vcTPeOrWznN1xW0eh4=.42c6b5e7-acda-4b0f-8dc1-afcd60bd6dfa@github.com>

On Wed, 3 Dec 2025 23:24:38 GMT, Rui Li <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 632:
>> 
>>> 630:   size_t get_usable_free_words(size_t free_bytes) const;
>>> 631: 
>>> 632:   void log_freeset_stats(ShenandoahFreeSetPartitionId partition_id, LogStream& ls);
>> 
>> `log_freeset_stats` should probably be `private`.
>
> I thought it was private already? The `private` starts from [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp#L478). Or, if you expand this section a bit to line 636, another `public` starts after these declaration.

:face-palm:, you're right. I misread the diff.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2586958311

From eastigeevich at openjdk.org  Wed Dec  3 23:58:04 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 23:58:04 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
Message-ID: <g9ktblHsa6_ShZqjSfHQgts0Ap9y7qRPr5XMao0A-LU=.170d25dc-f979-479a-8b33-47a014bc7a42@github.com>

On Wed, 3 Dec 2025 15:42:38 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>>  
>> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
>> - Disable coherent icache.
>> - Trap IC IVAU instructions.
>> - Execute:
>>    - `tlbi vae3is, xzr`
>>    - `dsb sy`
>>  
>>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>>  
>> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
>> 
>> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
>> 
>> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
>> 
>> Changes include:
>> 
>> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
>> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
>> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
>> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
>> 
>> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
>> 
>> - Baseline
>> 
>> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1...
>
> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Fix linux-cross-compile build aarch64
>  - Merge branch 'master' into JDK-8370947
>  - Remove trailing whitespaces
>  - Add support of deferred icache invalidation to other GCs and JIT
>  - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence
>  - Add jtreg test
>  - Fix linux-cross-compile aarch64 build
>  - Fix regressions for Java methods without field accesses
>  - Fix code style
>  - Correct ifdef; Add dsb after ic
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f

src/hotspot/os_cpu/linux_aarch64/icache_linux_aarch64.hpp line 114:

> 112:   _code = nullptr;
> 113:   _size = 0;
> 114:   _mode = ICacheInvalidation::NOT_NEEDED;

This should be inside IF.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2586966933

From wkemper at openjdk.org  Thu Dec  4 00:41:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Dec 2025 00:41:00 GMT
Subject: RFR: 8373056: Shenandoah: Remove unnecessary use of
 ShenandoahAllocRequest.type() [v2]
In-Reply-To: <1wB8K5uAm9h-sVDOlHskuhpH_kNuJIcxhBTHrkfDck0=.07cd6bd4-5cc5-4ec6-afbb-bb4b9cfa1cde@github.com>
References: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
 <1wB8K5uAm9h-sVDOlHskuhpH_kNuJIcxhBTHrkfDck0=.07cd6bd4-5cc5-4ec6-afbb-bb4b9cfa1cde@github.com>
Message-ID: <rumXHNW3_sFP1dLw_5LXCEJ1Lz1fwqByzpswwbWmLSY=.68ed38ad-0fea-4cbb-9b2d-721830281326@github.com>

On Wed, 3 Dec 2025 23:30:21 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Follow up on the feedback/comments on PR https://github.com/openjdk/jdk/pull/28521 for bug [JDK-8372566](https://bugs.openjdk.org/browse/JDK-8372566), we should avoid using ShenandoahAllocRequest.type() directly if possible, in most of cases we don't need to directly use alloc type, the inline member methods provided by ShenandoahAllocRequest should be sufficient.
>> 
>> In the PR, I have removed most of the places where ShenandoahAllocRequest.type() directly used, there will be only one place left after the change:
>> * ShenandoahFreeSet::allocate (This one will be removed with PR https://github.com/openjdk/jdk/pull/26171)
>> 
>> Also did small code rearrangement for ShenandoahOldGeneration::configure_plab_for_current_thread 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [ ] GHA
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8373056
>  - Remove direct use of alloc type from ShenandoahHeapRegion::adjust_alloc_metadata
>  - Revert log change
>  - Remove unnecessary use of ShenandoahAllocRequest.type()

Looks good. Left a minor nit about a now stale comment.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 198:

> 196: void
> 197: ShenandoahOldGeneration::configure_plab_for_current_thread(const ShenandoahAllocRequest &req) {
> 198:   // Note: Even when a mutator is performing a promotion outside a LAB, we use a 'shared_gc' request.

Is this comment vestigial now? This method doesn't handle shared allocations anymore.

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28649#pullrequestreview-3537426868
PR Review Comment: https://git.openjdk.org/jdk/pull/28649#discussion_r2587024810

From ysr at openjdk.org  Thu Dec  4 01:22:57 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Dec 2025 01:22:57 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
 [v2]
In-Reply-To: <zXMdo0vjaMhDeoe087_RtjFiFiPEQONUuCKb0rk6tY8=.5dd40b40-52b8-4d58-8616-30765125ea47@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
 <zXMdo0vjaMhDeoe087_RtjFiFiPEQONUuCKb0rk6tY8=.5dd40b40-52b8-4d58-8616-30765125ea47@github.com>
Message-ID: <GvMkUpaBM6nUP5vbr1fdJk_CAe7_MOWewBpybGLIUU0=.32ef61e7-df7f-49f7-bb81-25c173b7ab1d@github.com>

On Wed, 3 Dec 2025 22:08:11 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.
>> 
>> A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566
>> 
>> This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix up comment and remove additional assert from previous commit

One more fix to the comment.

LGTM otherwise. Thanks for the cleanups.

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

> 370:   //    and then too only during promotion/evacuation phases. Thus there is no danger
> 371:   //    of races between reading from and writing to the object start array,
> 372:   //    or of asking partially initialized objects their size (in the loop below).

Remove reference to "in the loop below".

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28642#pullrequestreview-3537496302
PR Review Comment: https://git.openjdk.org/jdk/pull/28642#discussion_r2587092135

From xpeng at openjdk.org  Thu Dec  4 01:23:55 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 4 Dec 2025 01:23:55 GMT
Subject: RFR: 8373056: Shenandoah: Remove unnecessary use of
 ShenandoahAllocRequest.type() [v3]
In-Reply-To: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
References: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
Message-ID: <ByrvYRfyYkpa70X6U1N_cc1zLc1L98u-n-i0xhhxy_k=.605dcacd-d2d1-4492-b3d1-0024c3d36b65@github.com>

> Follow up on the feedback/comments on PR https://github.com/openjdk/jdk/pull/28521 for bug [JDK-8372566](https://bugs.openjdk.org/browse/JDK-8372566), we should avoid using ShenandoahAllocRequest.type() directly if possible, in most of cases we don't need to directly use alloc type, the inline member methods provided by ShenandoahAllocRequest should be sufficient.
> 
> In the PR, I have removed most of the places where ShenandoahAllocRequest.type() directly used, there will be only one place left after the change:
> * ShenandoahFreeSet::allocate (This one will be removed with PR https://github.com/openjdk/jdk/pull/26171)
> 
> Also did small code rearrangement for ShenandoahOldGeneration::configure_plab_for_current_thread 
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [ ] GHA

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Remove outdated comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28649/files
  - new: https://git.openjdk.org/jdk/pull/28649/files/59087c8e..57305932

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

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

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

From xpeng at openjdk.org  Thu Dec  4 01:23:59 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 4 Dec 2025 01:23:59 GMT
Subject: RFR: 8373056: Shenandoah: Remove unnecessary use of
 ShenandoahAllocRequest.type() [v2]
In-Reply-To: <rumXHNW3_sFP1dLw_5LXCEJ1Lz1fwqByzpswwbWmLSY=.68ed38ad-0fea-4cbb-9b2d-721830281326@github.com>
References: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
 <1wB8K5uAm9h-sVDOlHskuhpH_kNuJIcxhBTHrkfDck0=.07cd6bd4-5cc5-4ec6-afbb-bb4b9cfa1cde@github.com>
 <rumXHNW3_sFP1dLw_5LXCEJ1Lz1fwqByzpswwbWmLSY=.68ed38ad-0fea-4cbb-9b2d-721830281326@github.com>
Message-ID: <D-gIqluikKYxUlWgMUjuUtQww0Rf3VNcYlafKLSxRzM=.270a4cdb-79d7-4395-b7f1-a111ed401494@github.com>

On Thu, 4 Dec 2025 00:36:56 GMT, William Kemper <wkemper 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 four additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8373056
>>  - Remove direct use of alloc type from ShenandoahHeapRegion::adjust_alloc_metadata
>>  - Revert log change
>>  - Remove unnecessary use of ShenandoahAllocRequest.type()
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 198:
> 
>> 196: void
>> 197: ShenandoahOldGeneration::configure_plab_for_current_thread(const ShenandoahAllocRequest &req) {
>> 198:   // Note: Even when a mutator is performing a promotion outside a LAB, we use a 'shared_gc' request.
> 
> Is this comment vestigial now? This method doesn't handle shared allocations anymore.

Yeah, it is outdated, I will remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28649#discussion_r2587092735

From ysr at openjdk.org  Thu Dec  4 01:27:58 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Dec 2025 01:27:58 GMT
Subject: RFR: 8373054: Shenandoah: Remove unnecessary
 BarrierSetNMethod::arm in shenandoahCodeRoots [v2]
In-Reply-To: <X2WC7PonMkLuEs08wOA8N0U6aiLnOdqq6BJHlJlR7Y0=.2186a96e-1b29-41fd-95f5-77d943134b6b@github.com>
References: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
 <X2WC7PonMkLuEs08wOA8N0U6aiLnOdqq6BJHlJlR7Y0=.2186a96e-1b29-41fd-95f5-77d943134b6b@github.com>
Message-ID: <3dmdwyrhOIf8HobQN8f_s_OuhA1DI-cMTuJ7jD-oCUU=.ca7fa0a7-a41e-46c4-8d86-435f02db1c9b@github.com>

On Wed, 3 Dec 2025 22:07:15 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> The call to arm is redundant, and can be replaced with an assert to ensure the precondition remains true.
>> 
>> The same set of tier1 tests pass before and after this change with a fastdebug and Shenandoah GC.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix misleading comment in previous commit

LGTM

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28648#pullrequestreview-3537506166

From xpeng at openjdk.org  Thu Dec  4 01:29:55 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 4 Dec 2025 01:29:55 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
 [v2]
In-Reply-To: <zXMdo0vjaMhDeoe087_RtjFiFiPEQONUuCKb0rk6tY8=.5dd40b40-52b8-4d58-8616-30765125ea47@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
 <zXMdo0vjaMhDeoe087_RtjFiFiPEQONUuCKb0rk6tY8=.5dd40b40-52b8-4d58-8616-30765125ea47@github.com>
Message-ID: <bjgbO5jouhxrCX2WweaPQSWH2GFD8Lr3iqBPsHfLBms=.6b7035b3-881a-4995-8efa-e6abfa3447de@github.com>

On Wed, 3 Dec 2025 22:08:11 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.
>> 
>> A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566
>> 
>> This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix up comment and remove additional assert from previous commit

LGTM, thanks for looking into this.

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

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28642#pullrequestreview-3537509599

From duke at openjdk.org  Thu Dec  4 01:43:36 2025
From: duke at openjdk.org (Rui Li)
Date: Thu, 4 Dec 2025 01:43:36 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect [v2]
In-Reply-To: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
Message-ID: <enUPkRhtUmg82UFf9PN53P6OYmHeWpcfzqC1_avPzII=.8d719bd8-2601-4613-82c1-d1350b1005d8@github.com>

> Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 
> 
> Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:
> 
> 
> available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
> soft_tail = Xmx - soft_max
> if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 
> 
> 
> The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.
> 
> 
> Suggested fix: when deciding when to trigger gc, use logic similar to below:
> 
> mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
> available = mutator_soft_capacity - used;
> if (available < mutator_soft_capacity) // trigger gc
> ``` 
> 
> -------
> This change also improved gc logging:
> 
> Before:
> 
> [6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
> [6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
> external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B
> 
> 
> After:
> 
> [8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
> [8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
> 1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
> 1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
> 122, Reserved: 102M, Max free available in a single region: 1024K;

Rui Li has updated the pull request incrementally with two additional commits since the last revision:

 - Rename soft_available. Change Generation soft avail impl
 - log format fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28622/files
  - new: https://git.openjdk.org/jdk/pull/28622/files/b23e9ff1..103ce8f8

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

  Stats: 35 lines in 11 files changed: 2 ins; 7 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/28622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28622/head:pull/28622

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

From kdnilsen at openjdk.org  Thu Dec  4 01:50:04 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 4 Dec 2025 01:50:04 GMT
Subject: RFR: 8373048: Genshen: Remove dead code from Shenandoah
In-Reply-To: <cgZkXy2-7YVtGODIZ7m34Wemyx_enDgmSbubxipxZ0k=.44a2e2dd-2d5f-4931-b7bb-46ed8ef453b4@github.com>
References: <cgZkXy2-7YVtGODIZ7m34Wemyx_enDgmSbubxipxZ0k=.44a2e2dd-2d5f-4931-b7bb-46ed8ef453b4@github.com>
Message-ID: <rk0T4I2Jlbd9n-2_r5qmiuwUc0FjQleOf1DR-2JAj-4=.f24dd65f-d2a7-4bdb-9f3e-b81c65926c4c@github.com>

On Wed, 3 Dec 2025 20:55:09 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Trivial PR to remove dead code from Shenandoah. I noticed some dead code in shenandoahFreeSet.cpp when I was working on https://github.com/openjdk/jdk/pull/26171, this PR is to clean up the dead code in shenandoahFreeSet.cpp and some other files, no functional change at all.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] GHA

Thanks for this cleanup

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

PR Review: https://git.openjdk.org/jdk/pull/28647#pullrequestreview-3537557808

From duke at openjdk.org  Thu Dec  4 02:19:32 2025
From: duke at openjdk.org (Rui Li)
Date: Thu, 4 Dec 2025 02:19:32 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect [v3]
In-Reply-To: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
Message-ID: <nDhDGPSvzovYIsAP0jKr311TFj72ZzxR72UkkcofcVk=.cfd87dcc-1f74-4445-9be9-4f3ae1fbc478@github.com>

> Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 
> 
> Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:
> 
> 
> available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
> soft_tail = Xmx - soft_max
> if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 
> 
> 
> The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.
> 
> 
> Suggested fix: when deciding when to trigger gc, use logic similar to below:
> 
> mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
> available = mutator_soft_capacity - used;
> if (available < mutator_soft_capacity) // trigger gc
> ``` 
> 
> -------
> This change also improved gc logging:
> 
> Before:
> 
> [6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
> [6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
> external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B
> 
> 
> After:
> 
> [8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
> [8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
> 1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
> 1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
> 122, Reserved: 102M, Max free available in a single region: 1024K;

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

  Remove unused freeset includes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28622/files
  - new: https://git.openjdk.org/jdk/pull/28622/files/103ce8f8..599cc2d7

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

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

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

From aboldtch at openjdk.org  Thu Dec  4 06:16:05 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 4 Dec 2025 06:16:05 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <834LXpq7tgXkAdLSbu_J-OoTWWYhCxr40d-y80Z5z3M=.84badc91-3b8f-44db-800b-b48cd1dfc8d6@github.com>

On Wed, 3 Dec 2025 16:00:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - Fix linux-cross-compile build aarch64
>>  - Merge branch 'master' into JDK-8370947
>>  - Remove trailing whitespaces
>>  - Add support of deferred icache invalidation to other GCs and JIT
>>  - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence
>>  - Add jtreg test
>>  - Fix linux-cross-compile aarch64 build
>>  - Fix regressions for Java methods without field accesses
>>  - Fix code style
>>  - Correct ifdef; Add dsb after ic
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f
>
> src/hotspot/share/asm/codeBuffer.cpp line 939:
> 
>> 937:     // Move all the code and relocations to the new blob:
>> 938:     relocate_code_to(&cb);
>> 939:   }
> 
> Here and later, the preferred style is:
> 
> Suggestion:
> 
>   // Move all the code and relocations to the new blob:
>   {
>     ICacheInvalidationContext icic(ICacheInvalidation::NOT_NEEDED);
>     relocate_code_to(&cb);
>   }

Go ahead and use @shipilev suggested change. Following the code style of the surrounding code is usually my preference as well. 

_The style comments we had earlier all applied to the ZGC code which has a certain style._

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2587712509

From shade at openjdk.org  Thu Dec  4 07:16:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 4 Dec 2025 07:16:58 GMT
Subject: RFR: 8373054: Shenandoah: Remove unnecessary
 BarrierSetNMethod::arm in shenandoahCodeRoots [v2]
In-Reply-To: <X2WC7PonMkLuEs08wOA8N0U6aiLnOdqq6BJHlJlR7Y0=.2186a96e-1b29-41fd-95f5-77d943134b6b@github.com>
References: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
 <X2WC7PonMkLuEs08wOA8N0U6aiLnOdqq6BJHlJlR7Y0=.2186a96e-1b29-41fd-95f5-77d943134b6b@github.com>
Message-ID: <PrJWIwdJAJ8TyV25zeUwteqLpVQUzCXbe3GKrblXERQ=.a4798e24-0f26-47c4-888a-304ebbf8ed37@github.com>

On Wed, 3 Dec 2025 22:07:15 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> The call to arm is redundant, and can be replaced with an assert to ensure the precondition remains true.
>> 
>> The same set of tier1 tests pass before and after this change with a fastdebug and Shenandoah GC.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix misleading comment in previous commit

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28648#pullrequestreview-3538487931

From jsikstro at openjdk.org  Thu Dec  4 08:24:33 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 4 Dec 2025 08:24:33 GMT
Subject: RFR: 8373080: Parallel: gc/arguments/TestMinInitialErgonomics.java
 should not be run with Large Pages
Message-ID: <HbGe8_UJgpJTiPVQhIzyQwmbWiH8_xlt-xc79xMPTUw=.00928a6d-20ac-417a-8018-bba6f5ed960e@github.com>

Hello,

After [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150), Parallel might bump the initial and min heap sizes to match the requirements of using large pages. This is not reflected in the gc/arguments/TestMinInitialErgonomics.java test.

Parallel and Large pages are an exception to the "normal" behavior, so I suggest we run the test without Large pages moving forward.

Testing:
* Test fails locally when run with `-XX:+UseLargePages`, no longer runs when the `-XX:+UseLargePages` flag is added.

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

Commit messages:
 - 8373080: Parallel: gc/arguments/TestMinInitialErgonomics.java should not be run with Large Pages

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

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

From jsikstro at openjdk.org  Thu Dec  4 08:58:12 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 4 Dec 2025 08:58:12 GMT
Subject: RFR: 8373080: Parallel: gc/arguments/TestMinInitialErgonomics.java
 should not be run with Large Pages [v2]
In-Reply-To: <HbGe8_UJgpJTiPVQhIzyQwmbWiH8_xlt-xc79xMPTUw=.00928a6d-20ac-417a-8018-bba6f5ed960e@github.com>
References: <HbGe8_UJgpJTiPVQhIzyQwmbWiH8_xlt-xc79xMPTUw=.00928a6d-20ac-417a-8018-bba6f5ed960e@github.com>
Message-ID: <1Uxk7KdbIXLR5Ijq0gVTnlAM5GP7SL_jGuX-vIHai4o=.c04f624a-85f9-4f63-9e97-bd5bdbdcf371@github.com>

> Hello,
> 
> After [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150), Parallel might bump the initial and min heap sizes to match the requirements of using large pages. This is not reflected in the gc/arguments/TestMinInitialErgonomics.java test.
> 
> Parallel and Large pages are an exception to the "normal" behavior, so I suggest we run the test without Large pages moving forward.
> 
> Testing:
> * Test fails locally when run with `-XX:+UseLargePages`, no longer runs when the `-XX:+UseLargePages` flag is added.

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Typo fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28654/files
  - new: https://git.openjdk.org/jdk/pull/28654/files/d64e53dc..660b8b61

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

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

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

From ayang at openjdk.org  Thu Dec  4 09:17:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 09:17:14 GMT
Subject: RFR: 8373080: Parallel: gc/arguments/TestMinInitialErgonomics.java
 should not be run with Large Pages [v2]
In-Reply-To: <1Uxk7KdbIXLR5Ijq0gVTnlAM5GP7SL_jGuX-vIHai4o=.c04f624a-85f9-4f63-9e97-bd5bdbdcf371@github.com>
References: <HbGe8_UJgpJTiPVQhIzyQwmbWiH8_xlt-xc79xMPTUw=.00928a6d-20ac-417a-8018-bba6f5ed960e@github.com>
 <1Uxk7KdbIXLR5Ijq0gVTnlAM5GP7SL_jGuX-vIHai4o=.c04f624a-85f9-4f63-9e97-bd5bdbdcf371@github.com>
Message-ID: <a49CCFjH8342XLPyKQBWrN1tDAy7kk5KZ9NG9WDf4y0=.afbf57c2-8679-4df7-a12e-4627910f1aed@github.com>

On Thu, 4 Dec 2025 08:58:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> After [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150), Parallel might bump the initial and min heap sizes to match the requirements of using large pages. This is not reflected in the gc/arguments/TestMinInitialErgonomics.java test.
>> 
>> Parallel and Large pages are an exception to the "normal" behavior, so I suggest we run the test without Large pages moving forward.
>> 
>> Testing:
>> * Test fails locally when run with `-XX:+UseLargePages`, no longer runs when the `-XX:+UseLargePages` flag is added.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28654#pullrequestreview-3538873777

From aboldtch at openjdk.org  Thu Dec  4 09:24:56 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 4 Dec 2025 09:24:56 GMT
Subject: RFR: 8373080: Parallel: gc/arguments/TestMinInitialErgonomics.java
 should not be run with Large Pages [v2]
In-Reply-To: <1Uxk7KdbIXLR5Ijq0gVTnlAM5GP7SL_jGuX-vIHai4o=.c04f624a-85f9-4f63-9e97-bd5bdbdcf371@github.com>
References: <HbGe8_UJgpJTiPVQhIzyQwmbWiH8_xlt-xc79xMPTUw=.00928a6d-20ac-417a-8018-bba6f5ed960e@github.com>
 <1Uxk7KdbIXLR5Ijq0gVTnlAM5GP7SL_jGuX-vIHai4o=.c04f624a-85f9-4f63-9e97-bd5bdbdcf371@github.com>
Message-ID: <QuN2YuTv42-5GG2mCCAqbPi0xCP40nTyTHr9yVjuS6k=.dbef213f-c214-4fb0-a39e-e0ac131cf2f3@github.com>

On Thu, 4 Dec 2025 08:58:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> After [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150), Parallel might bump the initial and min heap sizes to match the requirements of using large pages. This is not reflected in the gc/arguments/TestMinInitialErgonomics.java test.
>> 
>> Parallel and Large pages are an exception to the "normal" behavior, so I suggest we run the test without Large pages moving forward.
>> 
>> Testing:
>> * Test fails locally when run with `-XX:+UseLargePages`, no longer runs when the `-XX:+UseLargePages` flag is added.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28654#pullrequestreview-3538906883

From tschatzl at openjdk.org  Thu Dec  4 09:24:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 4 Dec 2025 09:24:58 GMT
Subject: RFR: 8373025: Test:
 test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock [v3]
In-Reply-To: <9zSX9cB_iSIS1DcYhh4X0fQMg_0LxhzrFpEdVh73tPA=.b29ee8ec-3cbf-496c-a6d9-4d56831c75f1@github.com>
References: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
 <9zSX9cB_iSIS1DcYhh4X0fQMg_0LxhzrFpEdVh73tPA=.b29ee8ec-3cbf-496c-a6d9-4d56831c75f1@github.com>
Message-ID: <R6UrASGPhLLPGug-IbZ0cLUYQujPmErT_wqTpM8o_BU=.86475eef-7923-4f91-9689-66106c7d66cc@github.com>

On Wed, 3 Dec 2025 18:37:44 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
>> 
>> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
>> 
>> * Testing
>>   * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
>>   * GHA
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Remove problem-listing
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8373025
>  - Need to support windows as well
>  - Remove unused variable
>  - Fix the comment
>  - 8373025: Test: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28638#pullrequestreview-3538907853

From jsikstro at openjdk.org  Thu Dec  4 09:40:20 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 4 Dec 2025 09:40:20 GMT
Subject: Integrated: 8373080: Parallel:
 gc/arguments/TestMinInitialErgonomics.java should not be run with Large Pages
In-Reply-To: <HbGe8_UJgpJTiPVQhIzyQwmbWiH8_xlt-xc79xMPTUw=.00928a6d-20ac-417a-8018-bba6f5ed960e@github.com>
References: <HbGe8_UJgpJTiPVQhIzyQwmbWiH8_xlt-xc79xMPTUw=.00928a6d-20ac-417a-8018-bba6f5ed960e@github.com>
Message-ID: <aa2yY3W6yoA_D0pZITfcEeSgfS_S5B3sn6RKQp5owhg=.98532d15-e897-4ef1-8f85-6cde4a084f7f@github.com>

On Thu, 4 Dec 2025 08:17:24 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> After [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150), Parallel might bump the initial and min heap sizes to match the requirements of using large pages. This is not reflected in the gc/arguments/TestMinInitialErgonomics.java test.
> 
> Parallel and Large pages are an exception to the "normal" behavior, so I suggest we run the test without Large pages moving forward.
> 
> Testing:
> * Test fails locally when run with `-XX:+UseLargePages`, no longer runs when the `-XX:+UseLargePages` flag is added.

This pull request has now been integrated.

Changeset: 14000a25
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14000a25e6efcbe55171d4cc8c68170a8cf0406f
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8373080: Parallel: gc/arguments/TestMinInitialErgonomics.java should not be run with Large Pages

Reviewed-by: ayang, aboldtch

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

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

From jsikstro at openjdk.org  Thu Dec  4 09:40:18 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 4 Dec 2025 09:40:18 GMT
Subject: RFR: 8373080: Parallel: gc/arguments/TestMinInitialErgonomics.java
 should not be run with Large Pages [v2]
In-Reply-To: <1Uxk7KdbIXLR5Ijq0gVTnlAM5GP7SL_jGuX-vIHai4o=.c04f624a-85f9-4f63-9e97-bd5bdbdcf371@github.com>
References: <HbGe8_UJgpJTiPVQhIzyQwmbWiH8_xlt-xc79xMPTUw=.00928a6d-20ac-417a-8018-bba6f5ed960e@github.com>
 <1Uxk7KdbIXLR5Ijq0gVTnlAM5GP7SL_jGuX-vIHai4o=.c04f624a-85f9-4f63-9e97-bd5bdbdcf371@github.com>
Message-ID: <Y6c6-KctQ66KvZlcw91u0M9krqep4MIC83Gy-iod1sE=.13e2366e-e1b2-49dc-a25a-80fa539db224@github.com>

On Thu, 4 Dec 2025 08:58:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> After [JDK-8372150](https://bugs.openjdk.org/browse/JDK-8372150), Parallel might bump the initial and min heap sizes to match the requirements of using large pages. This is not reflected in the gc/arguments/TestMinInitialErgonomics.java test.
>> 
>> Parallel and Large pages are an exception to the "normal" behavior, so I suggest we run the test without Large pages moving forward.
>> 
>> Testing:
>> * Test fails locally when run with `-XX:+UseLargePages`, no longer runs when the `-XX:+UseLargePages` flag is added.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix

I'm going ahead and integrating this to reduce future CI noise. This change is very minimal.

Thank you for the reviews! @albertnetymk @xmas92

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

PR Comment: https://git.openjdk.org/jdk/pull/28654#issuecomment-3611113592

From ayang at openjdk.org  Thu Dec  4 10:10:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 10:10:44 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v2]
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <vdMrM6h6DqATiQV2Dv1BDQyKgAfEgFVbJ_AFIkTHgcE=.eb5bddd8-c148-4bf9-9425-fb3a3ca5f789@github.com>

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

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

 - review
 - Merge branch 'master' into sgc-is-in-early-return
 - sgc-is-in-early-return

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28393/files
  - new: https://git.openjdk.org/jdk/pull/28393/files/6f435555..515c739e

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

  Stats: 71805 lines in 1278 files changed: 47297 ins; 17182 del; 7326 mod
  Patch: https://git.openjdk.org/jdk/pull/28393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28393/head:pull/28393

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

From ayang at openjdk.org  Thu Dec  4 10:10:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 10:10:46 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <zw4hINhZs_P0o1x8uqNFBaa2v9f7xJH2EQ4rFfo4z90=.43bc1ea8-08d6-4cf5-a435-62127ae8dd64@github.com>

On Wed, 19 Nov 2025 15:39:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

After some offline discussion with Stefan, it's suggested that `CollectedHeap::is_in` should probably require callers to be in good state (e.g. not java-threads-in-native).

After removing the asserts in `MacroAssembler::set_narrow_klass`, I don't any crashes with placing such state-verification at the beginning of `is_in`. Therefore, it's probably best to make the assumption explicit (as a precondition).

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

PR Comment: https://git.openjdk.org/jdk/pull/28393#issuecomment-3611267941

From ayang at openjdk.org  Thu Dec  4 11:09:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 11:09:12 GMT
Subject: RFR: 8373087: Parallel: Rename PSGenerationPool to PSOldGenerationPool
Message-ID: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>

Trivial renaming to make it explicit that this class is only for old-gen.

Test: GHA

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

Commit messages:
 - pgc-rename

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

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

From stefank at openjdk.org  Thu Dec  4 11:11:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Dec 2025 11:11:21 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v2]
In-Reply-To: <vdMrM6h6DqATiQV2Dv1BDQyKgAfEgFVbJ_AFIkTHgcE=.eb5bddd8-c148-4bf9-9425-fb3a3ca5f789@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <vdMrM6h6DqATiQV2Dv1BDQyKgAfEgFVbJ_AFIkTHgcE=.eb5bddd8-c148-4bf9-9425-fb3a3ca5f789@github.com>
Message-ID: <-e8AEMg9uK0iEqJznCz9AwGvtrGGXFKXqOjQvkqpQUE=.3abe8aed-fc9b-428f-b9c6-efc684f10f85@github.com>

On Thu, 4 Dec 2025 10:10:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into sgc-is-in-early-return
>  - sgc-is-in-early-return

Please extract the verification into a helper function / macro

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3539419555

From jsikstro at openjdk.org  Thu Dec  4 11:24:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 4 Dec 2025 11:24:58 GMT
Subject: RFR: 8373087: Parallel: Rename PSGenerationPool to
 PSOldGenerationPool
In-Reply-To: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
References: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
Message-ID: <pf5_ryMcNVBFl6wixKUsoIsqTdXIZyuzQHIj5tnRFmE=.d5adbc88-e7f7-499b-8582-bf513c6bda19@github.com>

On Thu, 4 Dec 2025 11:01:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial renaming to make it explicit that this class is only for old-gen.
> 
> Test: GHA

Looks good.

There's a difference between `EdenMutableSpacePool` and `SurvivorMutableSpacePool` having "MutableSpace" in their names, but `PSOldGenerationPool` doesn't. I think we should remove the MutableSpace part, in a future RFE.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28657#pullrequestreview-3539485105

From ayang at openjdk.org  Thu Dec  4 11:28:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 11:28:40 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v3]
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <MletNy8VM8gz765TK_XbczaTYtyPS4Jsdc1mDmxWomQ=.ff5019b9-5dda-4237-840e-4fe53d9ef61e@github.com>

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28393/files
  - new: https://git.openjdk.org/jdk/pull/28393/files/515c739e..1a7bbae0

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

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

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

From iwalulya at openjdk.org  Thu Dec  4 11:47:58 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 4 Dec 2025 11:47:58 GMT
Subject: RFR: 8373087: Parallel: Rename PSGenerationPool to
 PSOldGenerationPool
In-Reply-To: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
References: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
Message-ID: <7Kfmr5dq9TKhXfjDnF1uBNQELEz0XfxJ68m0X-Ntvc0=.4c7af4b7-ed4f-4238-b64d-b690cbaaa929@github.com>

On Thu, 4 Dec 2025 11:01:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial renaming to make it explicit that this class is only for old-gen.
> 
> Test: GHA

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28657#pullrequestreview-3539581808

From tschatzl at openjdk.org  Thu Dec  4 13:34:12 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 4 Dec 2025 13:34:12 GMT
Subject: RFR: 8373087: Parallel: Rename PSGenerationPool to
 PSOldGenerationPool
In-Reply-To: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
References: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
Message-ID: <Hm_p2waTkILKlkjL8N4Hg8Ol1i9Q5ccYygut3gNUaN0=.50ae898b-40c4-402d-a704-b9b98d0060ef@github.com>

On Thu, 4 Dec 2025 11:01:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial renaming to make it explicit that this class is only for old-gen.
> 
> Test: GHA

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/parallel/psMemoryPool.cpp line 29:

> 27: PSOldGenerationPool::PSOldGenerationPool(PSOldGen* old_gen,
> 28:                                       const char* name,
> 29:                                       bool support_usage_threshold) :

Indentation?
Suggestion:

PSOldGenerationPool::PSOldGenerationPool(PSOldGen* old_gen,
                                         const char* name,
                                         bool support_usage_threshold) :

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

PR Review: https://git.openjdk.org/jdk/pull/28657#pullrequestreview-3540055016
PR Review Comment: https://git.openjdk.org/jdk/pull/28657#discussion_r2589097641

From tschatzl at openjdk.org  Thu Dec  4 13:39:30 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 4 Dec 2025 13:39:30 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v3]
In-Reply-To: <MletNy8VM8gz765TK_XbczaTYtyPS4Jsdc1mDmxWomQ=.ff5019b9-5dda-4237-840e-4fe53d9ef61e@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <MletNy8VM8gz765TK_XbczaTYtyPS4Jsdc1mDmxWomQ=.ff5019b9-5dda-4237-840e-4fe53d9ef61e@github.com>
Message-ID: <7Dy3XDFXp0_So2NClGXt-t88GSiTNeIQIIp8ngmTlxg=.fac7d5a5-8953-4b9a-b93f-651ec4cf845c@github.com>

On Thu, 4 Dec 2025 11:28:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

lgtm; I think `verify_not_in_native_if_java_thread` could be made a `NOT_DEBUG_RETURN` method which I tend to prefer to have less defines in the code. Either is fine to me though.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3540081518

From btaylor at openjdk.org  Thu Dec  4 16:06:13 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Thu, 4 Dec 2025 16:06:13 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
 [v3]
In-Reply-To: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
Message-ID: <7uBhjxIgI5nWimIcak1Id641QwQNKYhvXzo9_EQvFx8=.fa06f712-0cae-47bc-90d9-c650ae7ad86c@github.com>

> The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.
> 
> A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566
> 
> This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build

Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:

  Update another outdated comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28642/files
  - new: https://git.openjdk.org/jdk/pull/28642/files/eec662f6..830c8348

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

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

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

From wkemper at openjdk.org  Thu Dec  4 16:46:54 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Dec 2025 16:46:54 GMT
Subject: RFR: 8373056: Shenandoah: Remove unnecessary use of
 ShenandoahAllocRequest.type() [v3]
In-Reply-To: <ByrvYRfyYkpa70X6U1N_cc1zLc1L98u-n-i0xhhxy_k=.605dcacd-d2d1-4492-b3d1-0024c3d36b65@github.com>
References: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
 <ByrvYRfyYkpa70X6U1N_cc1zLc1L98u-n-i0xhhxy_k=.605dcacd-d2d1-4492-b3d1-0024c3d36b65@github.com>
Message-ID: <qPkeK50Rs4cAFM91kEDxJElyeIXWRhIrmMrSnP3CtKY=.148bc691-1b64-49c4-ad29-60664491ff6e@github.com>

On Thu, 4 Dec 2025 01:23:55 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Follow up on the feedback/comments on PR https://github.com/openjdk/jdk/pull/28521 for bug [JDK-8372566](https://bugs.openjdk.org/browse/JDK-8372566), we should avoid using ShenandoahAllocRequest.type() directly if possible, in most of cases we don't need to directly use alloc type, the inline member methods provided by ShenandoahAllocRequest should be sufficient.
>> 
>> In the PR, I have removed most of the places where ShenandoahAllocRequest.type() directly used, there will be only one place left after the change:
>> * ShenandoahFreeSet::allocate (This one will be removed with PR https://github.com/openjdk/jdk/pull/26171)
>> 
>> Also did small code rearrangement for ShenandoahOldGeneration::configure_plab_for_current_thread 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [ ] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove outdated comments

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28649#pullrequestreview-3540973973

From wkemper at openjdk.org  Thu Dec  4 16:44:54 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Dec 2025 16:44:54 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
 [v3]
In-Reply-To: <7uBhjxIgI5nWimIcak1Id641QwQNKYhvXzo9_EQvFx8=.fa06f712-0cae-47bc-90d9-c650ae7ad86c@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
 <7uBhjxIgI5nWimIcak1Id641QwQNKYhvXzo9_EQvFx8=.fa06f712-0cae-47bc-90d9-c650ae7ad86c@github.com>
Message-ID: <aN1misFGWrO5PEZRuD8wI3kuE0WttH4MkdqDVtvAy74=.934378f2-a642-4e3a-bfb0-56ab238ea386@github.com>

On Thu, 4 Dec 2025 16:06:13 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.
>> 
>> A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566
>> 
>> This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update another outdated comment

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28642#pullrequestreview-3540960610

From wkemper at openjdk.org  Thu Dec  4 16:55:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Dec 2025 16:55:22 GMT
Subject: RFR: 8373054: Shenandoah: Remove unnecessary
 BarrierSetNMethod::arm in shenandoahCodeRoots [v2]
In-Reply-To: <X2WC7PonMkLuEs08wOA8N0U6aiLnOdqq6BJHlJlR7Y0=.2186a96e-1b29-41fd-95f5-77d943134b6b@github.com>
References: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
 <X2WC7PonMkLuEs08wOA8N0U6aiLnOdqq6BJHlJlR7Y0=.2186a96e-1b29-41fd-95f5-77d943134b6b@github.com>
Message-ID: <q6-m8ARBwMmKPTJqXon3T0C48EaIXUi0Bj08rU9OC0Y=.3e896426-af1d-4df8-a5b1-ce8e9db07f0c@github.com>

On Wed, 3 Dec 2025 22:07:15 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> The call to arm is redundant, and can be replaced with an assert to ensure the precondition remains true.
>> 
>> The same set of tier1 tests pass before and after this change with a fastdebug and Shenandoah GC.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix misleading comment in previous commit

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28648#pullrequestreview-3541015046

From duke at openjdk.org  Thu Dec  4 18:37:47 2025
From: duke at openjdk.org (duke)
Date: Thu, 4 Dec 2025 18:37:47 GMT
Subject: RFR: 8373054: Shenandoah: Remove unnecessary
 BarrierSetNMethod::arm in shenandoahCodeRoots [v2]
In-Reply-To: <X2WC7PonMkLuEs08wOA8N0U6aiLnOdqq6BJHlJlR7Y0=.2186a96e-1b29-41fd-95f5-77d943134b6b@github.com>
References: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
 <X2WC7PonMkLuEs08wOA8N0U6aiLnOdqq6BJHlJlR7Y0=.2186a96e-1b29-41fd-95f5-77d943134b6b@github.com>
Message-ID: <penXQrDyzsPVpyxWxdKEX3LZJJtYFky4m-oMT8Q3DOM=.11c51f0e-883c-433a-9518-8ac697718fdb@github.com>

On Wed, 3 Dec 2025 22:07:15 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> The call to arm is redundant, and can be replaced with an assert to ensure the precondition remains true.
>> 
>> The same set of tier1 tests pass before and after this change with a fastdebug and Shenandoah GC.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix misleading comment in previous commit

@benty-amzn 
Your change (at version a1a9bf11e271967973fd4d759ce13b1137434be1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28648#issuecomment-3613782426

From duke at openjdk.org  Thu Dec  4 18:51:17 2025
From: duke at openjdk.org (Rui Li)
Date: Thu, 4 Dec 2025 18:51:17 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect [v3]
In-Reply-To: <DUWXfMCOfHqtZS88oDOZl1o-HUk1uQlPgePRq0SmScM=.d9fb25f4-7a40-4367-8af4-dd366edf76ba@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
 <DUWXfMCOfHqtZS88oDOZl1o-HUk1uQlPgePRq0SmScM=.d9fb25f4-7a40-4367-8af4-dd366edf76ba@github.com>
Message-ID: <aP8L7FJf_hOwgNjPp48qs0R_Kw13ydmjv-O2jOi10t4=.8103d440-087d-478e-b012-430b9a348312@github.com>

On Wed, 3 Dec 2025 18:44:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused freeset includes
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 258:
> 
>> 256:   size_t min_threshold = min_free_threshold();
>> 257:   if (available < min_threshold) {
>> 258:     log_trigger("Free (Soft mutator free) (%zu%s) is below minimum threshold (%zu%s)",
> 
> Changing this will break some log parsers, do we really need this?

Talked offline. `Free` is overloaded in logs. Sometimes it means soft free, sometimes it means total free. Make it as `Free (Soft)` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2590194712

From ayang at openjdk.org  Thu Dec  4 19:39:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 19:39:36 GMT
Subject: RFR: 8373087: Parallel: Rename PSGenerationPool to
 PSOldGenerationPool [v2]
In-Reply-To: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
References: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
Message-ID: <A5LKur7bF_2SrwlAabNj2T1otfc6neo7zUQhkNkTff0=.93c40608-0167-467e-b1ca-6942f3d09e1d@github.com>

> Trivial renaming to make it explicit that this class is only for old-gen.
> 
> Test: GHA

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28657/files
  - new: https://git.openjdk.org/jdk/pull/28657/files/c7922241..0393cec6

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

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

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

From ayang at openjdk.org  Thu Dec  4 19:46:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 19:46:35 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v4]
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <InyhuhR_Me5U37VRtH0OrcP2KrkaF_Il4WLvbPu6Mbk=.0982a838-b55a-488e-abca-65c77f37f34b@github.com>

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28393/files
  - new: https://git.openjdk.org/jdk/pull/28393/files/1a7bbae0..40ee3859

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

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

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

From wkemper at openjdk.org  Thu Dec  4 20:33:07 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Dec 2025 20:33:07 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect [v3]
In-Reply-To: <nDhDGPSvzovYIsAP0jKr311TFj72ZzxR72UkkcofcVk=.cfd87dcc-1f74-4445-9be9-4f3ae1fbc478@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
 <nDhDGPSvzovYIsAP0jKr311TFj72ZzxR72UkkcofcVk=.cfd87dcc-1f74-4445-9be9-4f3ae1fbc478@github.com>
Message-ID: <WfanjX_sZQeyd8QNG3cOsFRFt2MGaFY20GmKcM820mI=.820b90ff-0b92-4211-ad80-3a8d7a794e6b@github.com>

On Thu, 4 Dec 2025 02:19:32 GMT, Rui Li <duke at openjdk.org> wrote:

>> Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 
>> 
>> Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:
>> 
>> 
>> available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
>> soft_tail = Xmx - soft_max
>> if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 
>> 
>> 
>> The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.
>> 
>> 
>> Suggested fix: when deciding when to trigger gc, use logic similar to below:
>> 
>> mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
>> available = mutator_soft_capacity - used;
>> if (available < mutator_soft_capacity) // trigger gc
>> ``` 
>> 
>> -------
>> This change also improved gc logging:
>> 
>> Before:
>> 
>> [6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
>> [6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
>> external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B
>> 
>> 
>> After:
>> 
>> [8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
>> [8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
>> 1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
>> 1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
>> 122, Reserved: 102M, Max free available in a single region: 1024K;
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused freeset includes

src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp line 81:

> 79: }
> 80: 
> 81: size_t ShenandoahGlobalGeneration::soft_available_exclude_evac_reserve() const {

Two questions:
* How is this override different from the default implementation now?
* Should we not also take the minimum of this value and `free_set()->available()` as we do elsewhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2590478334

From wkemper at openjdk.org  Thu Dec  4 20:42:27 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Dec 2025 20:42:27 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification
Message-ID: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>

In some cases, the control thread may fail to observe an allocation failure. This results in the thread which failed to allocate waiting forever for the control thread to run a cycle. Depending on which thread fails to allocate, the process may not make progress.

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

Commit messages:
 - Expand scope of control lock so that it can't miss cancellation notifications

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

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

From eastigeevich at openjdk.org  Thu Dec  4 21:16:26 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 4 Dec 2025 21:16:26 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <7IU85M4fl7Hk58g_oBLgw5g9QEHDhmSCLN6K5IhH9YQ=.46291089-efb6-432f-ac17-3480200c494a@github.com>

On Wed, 3 Dec 2025 15:54:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - Fix linux-cross-compile build aarch64
>>  - Merge branch 'master' into JDK-8370947
>>  - Remove trailing whitespaces
>>  - Add support of deferred icache invalidation to other GCs and JIT
>>  - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence
>>  - Add jtreg test
>>  - Fix linux-cross-compile aarch64 build
>>  - Fix regressions for Java methods without field accesses
>>  - Fix code style
>>  - Correct ifdef; Add dsb after ic
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f
>
> src/hotspot/share/asm/codeBuffer.cpp line 371:
> 
>> 369:       !((oop_Relocation*)reloc)->oop_is_immediate()) {
>> 370:     _has_non_immediate_oops = true;
>> 371:   }
> 
> Honestly, this looks fragile? We can go into nmethods patching for some other reason, not for patching oops.
> 
> Also, we still might need to go and patch immediate oops? I see this:
> 
> 
>   // Instruct loadConP of x86_64.ad places oops in code that are not also
>   // listed in the oop section.
>   static bool mustIterateImmediateOopsInCode() { return true; }
> 
> 
> Is there a substantial loss is doing icache invalidation without checking for the existence of interesting oops? Do you have an idea how many methods this filters?

@shipilev 
Moving `ICacheInvalidationContext icic` to `nmethod::fix_oop_relocations` works. The fragile code is no more needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2590596345

From duke at openjdk.org  Thu Dec  4 21:24:04 2025
From: duke at openjdk.org (Rui Li)
Date: Thu, 4 Dec 2025 21:24:04 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect [v3]
In-Reply-To: <WfanjX_sZQeyd8QNG3cOsFRFt2MGaFY20GmKcM820mI=.820b90ff-0b92-4211-ad80-3a8d7a794e6b@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
 <nDhDGPSvzovYIsAP0jKr311TFj72ZzxR72UkkcofcVk=.cfd87dcc-1f74-4445-9be9-4f3ae1fbc478@github.com>
 <WfanjX_sZQeyd8QNG3cOsFRFt2MGaFY20GmKcM820mI=.820b90ff-0b92-4211-ad80-3a8d7a794e6b@github.com>
Message-ID: <T8kNS_VxIaQyQqlrFKJrAeCfe7Or3-U356mIdBlAJ9M=.5fa1411a-e661-4d01-b086-eceee40bb744@github.com>

On Thu, 4 Dec 2025 20:30:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused freeset includes
>
> src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp line 81:
> 
>> 79: }
>> 80: 
>> 81: size_t ShenandoahGlobalGeneration::soft_available_exclude_evac_reserve() const {
> 
> Two questions:
> * How is this override different from the default implementation now?
> * Should we not also take the minimum of this value and `free_set()->available()` as we do elsewhere?

- Good call. No functional differences except for a safety assert: `assert(max_capacity() >= soft_max`, which isn't that necessary since the app wouldn't start if this wasn't true: [code](https://github.com/openjdk/jdk/blob/8e653d394e45180e16714124ed6584f912eb5cba/src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp#L277). Will remove the override.
- I don't think it's needed for global. `free_set()->available()` (space reserved for mutators) could be smaller than `mutator_soft_max` when there's an old gen taking space. If there's no generation, the `mutator_soft_max` should always be less or equal than `free_set()->available()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2590621429

From btaylor at openjdk.org  Thu Dec  4 21:40:11 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Thu, 4 Dec 2025 21:40:11 GMT
Subject: Integrated: 8373054: Shenandoah: Remove unnecessary
 BarrierSetNMethod::arm in shenandoahCodeRoots
In-Reply-To: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
References: <0gQ6rQRdUyqFv7h48VYct_R6TSHQsauMiPpJeUEsc8E=.fb99f821-9249-49aa-a9c4-c257050c2208@github.com>
Message-ID: <h2sLzCf1CVN_v6JSYBISB1OJOTC2-UmSJY7TUyFpago=.3fd2d2da-9c59-4511-875c-3037f7880e73@github.com>

On Wed, 3 Dec 2025 21:33:50 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The call to arm is redundant, and can be replaced with an assert to ensure the precondition remains true.
> 
> The same set of tier1 tests pass before and after this change with a fastdebug and Shenandoah GC.

This pull request has now been integrated.

Changeset: 5ec5a6ea
Author:    Ben Taylor <btaylor at openjdk.org>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ec5a6ea6c8e887b4e21f81e382f57129bffbab8
Stats:     4 lines in 1 file changed: 0 ins; 1 del; 3 mod

8373054: Shenandoah: Remove unnecessary BarrierSetNMethod::arm in shenandoahCodeRoots

Reviewed-by: wkemper, ysr, shade

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

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

From duke at openjdk.org  Thu Dec  4 21:50:52 2025
From: duke at openjdk.org (duke)
Date: Thu, 4 Dec 2025 21:50:52 GMT
Subject: RFR: 8373039: Remove Incorrect Asserts in shenandoahScanRemembered
 [v3]
In-Reply-To: <7uBhjxIgI5nWimIcak1Id641QwQNKYhvXzo9_EQvFx8=.fa06f712-0cae-47bc-90d9-c650ae7ad86c@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
 <7uBhjxIgI5nWimIcak1Id641QwQNKYhvXzo9_EQvFx8=.fa06f712-0cae-47bc-90d9-c650ae7ad86c@github.com>
Message-ID: <sj7PsuM4_Nsb87KJrgiZWtB8rx18APTPrEaQhTEDd5c=.aec3adbc-2380-45cf-8de5-d1b1c05211cd@github.com>

On Thu, 4 Dec 2025 16:06:13 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.
>> 
>> A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566
>> 
>> This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update another outdated comment

@benty-amzn 
Your change (at version 830c83480540d57b147fe26f6ea6742b4788c5e2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28642#issuecomment-3614461395

From btaylor at openjdk.org  Thu Dec  4 22:15:07 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Thu, 4 Dec 2025 22:15:07 GMT
Subject: Integrated: 8373039: Remove Incorrect Asserts in
 shenandoahScanRemembered
In-Reply-To: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
References: <mVUcR9znbSmpLfOQ4JxSIhxVWyLQT2kdNAwp9GDJ0LU=.a74986d8-f618-476c-abb1-6cdf438b42d8@github.com>
Message-ID: <_arO7HyaZNuiCeydQ9IKZuIZfi1z6sNH--IIbk49Mcc=.68fa2fa2-e0dc-40bd-934f-49ae0b4b39ec@github.com>

On Wed, 3 Dec 2025 17:16:02 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The `Klass->is_valid` asserts in this file do not hold the required `ClassLoaderDataGraph_lock` and can cause a crash.
> 
> A similar issue was seen in https://bugs.openjdk.org/browse/JDK-8372566
> 
> This change passes all tests in `TEST=hotspot_gc_shenandoah` with a fastdebug build

This pull request has now been integrated.

Changeset: c8b30da7
Author:    Ben Taylor <btaylor at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8b30da7ef48edb3d43e07d2c1b8622d8123c3a9
Stats:     13 lines in 1 file changed: 0 ins; 10 del; 3 mod

8373039: Remove Incorrect Asserts in shenandoahScanRemembered

Reviewed-by: wkemper, ysr, xpeng

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

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

From kdnilsen at openjdk.org  Thu Dec  4 22:23:41 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 4 Dec 2025 22:23:41 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification
In-Reply-To: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
Message-ID: <ypkQl_HwnLRiEwV5QyJYMWBsBBufr-FVFQNRfXO971g=.f06512b8-49e5-4f30-9cbd-f6db3dd756f0@github.com>

On Thu, 4 Dec 2025 20:35:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In some cases, the control thread may fail to observe an allocation failure. This results in the thread which failed to allocate waiting forever for the control thread to run a cycle. Depending on which thread fails to allocate, the process may not make progress.

Thanks.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28665#pullrequestreview-3542353932

From kdnilsen at openjdk.org  Thu Dec  4 22:31:14 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 4 Dec 2025 22:31:14 GMT
Subject: RFR: 8373056: Shenandoah: Remove unnecessary use of
 ShenandoahAllocRequest.type() [v3]
In-Reply-To: <ByrvYRfyYkpa70X6U1N_cc1zLc1L98u-n-i0xhhxy_k=.605dcacd-d2d1-4492-b3d1-0024c3d36b65@github.com>
References: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
 <ByrvYRfyYkpa70X6U1N_cc1zLc1L98u-n-i0xhhxy_k=.605dcacd-d2d1-4492-b3d1-0024c3d36b65@github.com>
Message-ID: <9NmDxH8twYZVjup5VIUUI3Aw-dfOINY8eyPTNnFEZNA=.af38ae63-c607-46f4-979f-632eb7a44817@github.com>

On Thu, 4 Dec 2025 01:23:55 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Follow up on the feedback/comments on PR https://github.com/openjdk/jdk/pull/28521 for bug [JDK-8372566](https://bugs.openjdk.org/browse/JDK-8372566), we should avoid using ShenandoahAllocRequest.type() directly if possible, in most of cases we don't need to directly use alloc type, the inline member methods provided by ShenandoahAllocRequest should be sufficient.
>> 
>> In the PR, I have removed most of the places where ShenandoahAllocRequest.type() directly used, there will be only one place left after the change:
>> * ShenandoahFreeSet::allocate (This one will be removed with PR https://github.com/openjdk/jdk/pull/26171)
>> 
>> Also did small code rearrangement for ShenandoahOldGeneration::configure_plab_for_current_thread 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove outdated comments

Thanks.  NIce improvements to code.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28649#pullrequestreview-3542376515

From xpeng at openjdk.org  Thu Dec  4 23:59:14 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 4 Dec 2025 23:59:14 GMT
Subject: RFR: 8373056: Shenandoah: Remove unnecessary use of
 ShenandoahAllocRequest.type() [v3]
In-Reply-To: <ByrvYRfyYkpa70X6U1N_cc1zLc1L98u-n-i0xhhxy_k=.605dcacd-d2d1-4492-b3d1-0024c3d36b65@github.com>
References: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
 <ByrvYRfyYkpa70X6U1N_cc1zLc1L98u-n-i0xhhxy_k=.605dcacd-d2d1-4492-b3d1-0024c3d36b65@github.com>
Message-ID: <Xn2uM3XzzvHBF7X05k_lCXvdtpieJe2g6a3jcO8NAzA=.e8860b8b-e8ec-49a2-bcf9-0f4ada18ba02@github.com>

On Thu, 4 Dec 2025 01:23:55 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Follow up on the feedback/comments on PR https://github.com/openjdk/jdk/pull/28521 for bug [JDK-8372566](https://bugs.openjdk.org/browse/JDK-8372566), we should avoid using ShenandoahAllocRequest.type() directly if possible, in most of cases we don't need to directly use alloc type, the inline member methods provided by ShenandoahAllocRequest should be sufficient.
>> 
>> In the PR, I have removed most of the places where ShenandoahAllocRequest.type() directly used, there will be only one place left after the change:
>> * ShenandoahFreeSet::allocate (This one will be removed with PR https://github.com/openjdk/jdk/pull/26171)
>> 
>> Also did small code rearrangement for ShenandoahOldGeneration::configure_plab_for_current_thread 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove outdated comments

Thanks all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28649#issuecomment-3614774632

From xpeng at openjdk.org  Thu Dec  4 23:59:16 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 4 Dec 2025 23:59:16 GMT
Subject: Integrated: 8373056: Shenandoah: Remove unnecessary use of
 ShenandoahAllocRequest.type()
In-Reply-To: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
References: <7nPmLquaKl_2EEk2JfsH1ForsyITXxmPAe8UxbazO9E=.e617c2c9-4a9f-44d5-ac08-33903e6deab9@github.com>
Message-ID: <m6uybfQehD-_rZMS3V1RlLN77uwn64JNx7fR98nITPY=.d15f8561-9fcd-4dcc-92c2-a3c476495b5b@github.com>

On Wed, 3 Dec 2025 23:02:17 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Follow up on the feedback/comments on PR https://github.com/openjdk/jdk/pull/28521 for bug [JDK-8372566](https://bugs.openjdk.org/browse/JDK-8372566), we should avoid using ShenandoahAllocRequest.type() directly if possible, in most of cases we don't need to directly use alloc type, the inline member methods provided by ShenandoahAllocRequest should be sufficient.
> 
> In the PR, I have removed most of the places where ShenandoahAllocRequest.type() directly used, there will be only one place left after the change:
> * ShenandoahFreeSet::allocate (This one will be removed with PR https://github.com/openjdk/jdk/pull/26171)
> 
> Also did small code rearrangement for ShenandoahOldGeneration::configure_plab_for_current_thread 
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] GHA

This pull request has now been integrated.

Changeset: 15f25389
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15f25389435288881644f7aeab48fd2eae410999
Stats:     80 lines in 6 files changed: 12 ins; 21 del; 47 mod

8373056: Shenandoah: Remove unnecessary use of ShenandoahAllocRequest.type()

Reviewed-by: wkemper, kdnilsen

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

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

From xpeng at openjdk.org  Fri Dec  5 00:27:20 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 5 Dec 2025 00:27:20 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done unconditionally
 by arraycopy_marking if the array is in an old region
Message-ID: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>

Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2

It is caused by the behavior change from follow code:

Original:

  if (ShenandoahSATBBarrier) {
    T* array = dst;
    HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
    ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
    if (is_old_marking) {
      // Generational, old marking
      assert(_heap->mode()->is_generational(), "Invariant");
      if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
        arraycopy_work<T, false, false, true>(array, count);
      }
    } else if (_heap->mode()->is_generational()) {
      // Generational, young marking
      if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
        arraycopy_work<T, false, false, true>(array, count);
      }
    } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
      // Non-generational, marking
      arraycopy_work<T, false, false, true>(array, count);
    }
  }

New:

  if (ShenandoahSATBBarrier) {
    if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
      arraycopy_work<T, false, false, true>(dst, count);
    }
  }



With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.

### Test
- [x] hotspot_gc_shenandoah
- [ ] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
- [ ] GHA

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

Commit messages:
 - Reorder the code
 - Assert only when the obj been pointed to is in young
 - Add assert to check card table to sure card table is correct
 - Merge branch 'openjdk:master' into JDK-8372498
 - arraycopy_work should be done unconditionally if the array is in an old region

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

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

From xpeng at openjdk.org  Fri Dec  5 02:03:34 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 5 Dec 2025 02:03:34 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v2]
In-Reply-To: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
Message-ID: <uKE3pUFlh7-SxhlEkWqwOcbwl-FHEEZjKspc2cxg7rk=.2831d928-264e-4605-bb6e-12beb7dab647@github.com>

> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
> 
> It is caused by the behavior change from follow code:
> 
> Original:
> 
>   if (ShenandoahSATBBarrier) {
>     T* array = dst;
>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>     if (is_old_marking) {
>       // Generational, old marking
>       assert(_heap->mode()->is_generational(), "Invariant");
>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (_heap->mode()->is_generational()) {
>       // Generational, young marking
>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>       // Non-generational, marking
>       arraycopy_work<T, false, false, true>(array, count);
>     }
>   }
> 
> New:
> 
>   if (ShenandoahSATBBarrier) {
>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>       arraycopy_work<T, false, false, true>(dst, count);
>     }
>   }
> 
> 
> 
> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [ ] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
> - [ ] GHA

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  uncomment the new added assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28669/files
  - new: https://git.openjdk.org/jdk/pull/28669/files/44938dc7..5b951e6d

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

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

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

From xpeng at openjdk.org  Fri Dec  5 07:24:35 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 5 Dec 2025 07:24:35 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v3]
In-Reply-To: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
Message-ID: <V55h5UMZWBeTcLQOKbl7-rTln-f1E9ht4H9D3SNCaeI=.84b900f6-33c1-48dd-84ca-2c75553399e2@github.com>

> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
> 
> It is caused by the behavior change from follow code:
> 
> Original:
> 
>   if (ShenandoahSATBBarrier) {
>     T* array = dst;
>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>     if (is_old_marking) {
>       // Generational, old marking
>       assert(_heap->mode()->is_generational(), "Invariant");
>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (_heap->mode()->is_generational()) {
>       // Generational, young marking
>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>       // Non-generational, marking
>       arraycopy_work<T, false, false, true>(array, count);
>     }
>   }
> 
> New:
> 
>   if (ShenandoahSATBBarrier) {
>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>       arraycopy_work<T, false, false, true>(dst, count);
>     }
>   }
> 
> 
> 
> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
> - [x] GHA

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Remove the asset code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28669/files
  - new: https://git.openjdk.org/jdk/pull/28669/files/5b951e6d..85acca0c

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

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

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

From syan at openjdk.org  Fri Dec  5 07:26:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 5 Dec 2025 07:26:56 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v2]
In-Reply-To: <uKE3pUFlh7-SxhlEkWqwOcbwl-FHEEZjKspc2cxg7rk=.2831d928-264e-4605-bb6e-12beb7dab647@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <uKE3pUFlh7-SxhlEkWqwOcbwl-FHEEZjKspc2cxg7rk=.2831d928-264e-4605-bb6e-12beb7dab647@github.com>
Message-ID: <3ib3dmwah2lDF7aNTiGY-4lav-SXfYPXAdu2AKSvtGM=.b5cdd6b8-3b40-41bc-8ce4-46e934928756@github.com>

On Fri, 5 Dec 2025 02:03:34 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncomment the new added assert

After apply the proposed patch, the jvm crash do not observed by run the test 1000 times. But there is one "java.lang.OutOfMemoryError: Java heap space" test fails observed.

[848.log](https://github.com/user-attachments/files/23955591/848.log)

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

PR Comment: https://git.openjdk.org/jdk/pull/28669#issuecomment-3615615694

From xpeng at openjdk.org  Fri Dec  5 07:42:56 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 5 Dec 2025 07:42:56 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v2]
In-Reply-To: <3ib3dmwah2lDF7aNTiGY-4lav-SXfYPXAdu2AKSvtGM=.b5cdd6b8-3b40-41bc-8ce4-46e934928756@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <uKE3pUFlh7-SxhlEkWqwOcbwl-FHEEZjKspc2cxg7rk=.2831d928-264e-4605-bb6e-12beb7dab647@github.com>
 <3ib3dmwah2lDF7aNTiGY-4lav-SXfYPXAdu2AKSvtGM=.b5cdd6b8-3b40-41bc-8ce4-46e934928756@github.com>
Message-ID: <fcjuVH8d2VxK3YRavQmlSbdEPsN4C0K6tziEDrdpFkg=.bdb09778-a207-4df2-a2d4-90f71a96bb31@github.com>

On Fri, 5 Dec 2025 07:24:13 GMT, SendaoYan <syan at openjdk.org> wrote:

> After apply the proposed patch, the jvm crash do not observed by run the test 1000 times. But there is one "java.lang.OutOfMemoryError: Java heap space" test fails observed.
> 
> [848.log](https://github.com/user-attachments/files/23955591/848.log)

Thank you Sendao for the test and verification!

The OOM should be a unrelated issue, I'm not if there is open bug for it or not, please create a new one if there isn't.

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

PR Comment: https://git.openjdk.org/jdk/pull/28669#issuecomment-3615655399

From xpeng at openjdk.org  Fri Dec  5 07:42:57 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 5 Dec 2025 07:42:57 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v2]
In-Reply-To: <fcjuVH8d2VxK3YRavQmlSbdEPsN4C0K6tziEDrdpFkg=.bdb09778-a207-4df2-a2d4-90f71a96bb31@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <uKE3pUFlh7-SxhlEkWqwOcbwl-FHEEZjKspc2cxg7rk=.2831d928-264e-4605-bb6e-12beb7dab647@github.com>
 <3ib3dmwah2lDF7aNTiGY-4lav-SXfYPXAdu2AKSvtGM=.b5cdd6b8-3b40-41bc-8ce4-46e934928756@github.com>
 <fcjuVH8d2VxK3YRavQmlSbdEPsN4C0K6tziEDrdpFkg=.bdb09778-a207-4df2-a2d4-90f71a96bb31@github.com>
Message-ID: <TjADHJolhFYZPg-j7mb5jjOrFuJyyq6ejc3UBGoy-SQ=.59fa675c-63f4-4866-b929-b74ff1d67e45@github.com>

On Fri, 5 Dec 2025 07:39:53 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> > After apply the proposed patch, the jvm crash do not observed by run the test 1000 times. But there is one "java.lang.OutOfMemoryError: Java heap space" test fails observed.
> > [848.log](https://github.com/user-attachments/files/23955591/848.log)
> 
> Thank you Sendao for the test and verification!
> 
> The OOM should be a unrelated issue, I'm not if there is open bug for it or not, please create a new one if there isn't.

Found it, https://bugs.openjdk.org/browse/JDK-8298781

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

PR Comment: https://git.openjdk.org/jdk/pull/28669#issuecomment-3615657332

From stefank at openjdk.org  Fri Dec  5 07:53:18 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Dec 2025 07:53:18 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v4]
In-Reply-To: <InyhuhR_Me5U37VRtH0OrcP2KrkaF_Il4WLvbPu6Mbk=.0982a838-b55a-488e-abca-65c77f37f34b@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <InyhuhR_Me5U37VRtH0OrcP2KrkaF_Il4WLvbPu6Mbk=.0982a838-b55a-488e-abca-65c77f37f34b@github.com>
Message-ID: <OfZ_wBJQgRC2-KvUae0ZGTscYRaSmaEQQ4nf4AL1o5g=.7bda4328-af74-48d4-9933-b07a595a550f@github.com>

On Thu, 4 Dec 2025 19:46:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Changes requested by stefank (Reviewer).

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

> 632: bool SerialHeap::is_in(const void* p) const {
> 633:   // precondition
> 634:   DEBUG_ONLY(verify_not_in_native_if_java_thread();)

No need for `DEBUG_ONLY` now that you've added `NOT_DEBUG_RETURN`
Suggestion:

  verify_not_in_native_if_java_thread();

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

PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3543492436
PR Review Comment: https://git.openjdk.org/jdk/pull/28393#discussion_r2591730326

From ayang at openjdk.org  Fri Dec  5 11:01:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 11:01:17 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v5]
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/gc/serial/serialHeap.cpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28393/files
  - new: https://git.openjdk.org/jdk/pull/28393/files/40ee3859..6f4f258d

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

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

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

From stefank at openjdk.org  Fri Dec  5 11:49:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Dec 2025 11:49:56 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v5]
In-Reply-To: <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>
Message-ID: <WJ_L53bROh1lDl6VInB-UwExF9LX7D3ba2cgKnoqR0I=.907238a1-7ba1-4781-ba23-b236a331e692@github.com>

On Fri, 5 Dec 2025 11:01:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/serial/serialHeap.cpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3544404740

From tschatzl at openjdk.org  Fri Dec  5 13:50:12 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 5 Dec 2025 13:50:12 GMT
Subject: RFR: 8373087: Parallel: Rename PSGenerationPool to
 PSOldGenerationPool [v2]
In-Reply-To: <A5LKur7bF_2SrwlAabNj2T1otfc6neo7zUQhkNkTff0=.93c40608-0167-467e-b1ca-6942f3d09e1d@github.com>
References: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
 <A5LKur7bF_2SrwlAabNj2T1otfc6neo7zUQhkNkTff0=.93c40608-0167-467e-b1ca-6942f3d09e1d@github.com>
Message-ID: <nUgXUyuK_Voaj_dPvoVk5cVevZOAEDQfCESG3xoGSio=.fcd508b9-13e8-488a-bf41-77bf04d708c1@github.com>

On Thu, 4 Dec 2025 19:39:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial renaming to make it explicit that this class is only for old-gen.
>> 
>> Test: GHA
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28657#pullrequestreview-3544836974

From xpeng at openjdk.org  Fri Dec  5 16:25:22 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 5 Dec 2025 16:25:22 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v4]
In-Reply-To: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
Message-ID: <vP0d16NMDolqlf_8H-gtZQ_zGE89dqHkqgkWgibH5mA=.75a696db-4746-49ed-8ba0-fb418d25b641@github.com>

> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
> 
> It is caused by the behavior change from follow code:
> 
> Original:
> 
>   if (ShenandoahSATBBarrier) {
>     T* array = dst;
>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>     if (is_old_marking) {
>       // Generational, old marking
>       assert(_heap->mode()->is_generational(), "Invariant");
>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (_heap->mode()->is_generational()) {
>       // Generational, young marking
>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>       // Non-generational, marking
>       arraycopy_work<T, false, false, true>(array, count);
>     }
>   }
> 
> New:
> 
>   if (ShenandoahSATBBarrier) {
>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>       arraycopy_work<T, false, false, true>(dst, count);
>     }
>   }
> 
> 
> 
> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
> - [x] GHA

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Add asserts back, the elem_ptr must be dirty either in read or write table

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28669/files
  - new: https://git.openjdk.org/jdk/pull/28669/files/85acca0c..53316bd3

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

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

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

From eastigeevich at openjdk.org  Fri Dec  5 17:52:20 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 5 Dec 2025 17:52:20 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v14]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <Z9pHy1Dz1gFWexsxfR1coHVGaHQDzL24trTRJ-2aR_o=.255edf2f-d25e-434d-8aca-d0af575f5006@github.com>

> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>  
> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
> - Disable coherent icache.
> - Trap IC IVAU instructions.
> - Execute:
>    - `tlbi vae3is, xzr`
>    - `dsb sy`
>  
>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>  
> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
> 
> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
> 
> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
> 
> Changes include:
> 
> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
> 
> - Baseline
> 
> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1Errata1542419 -XX:+UseZGC -XX:ZYoungGCThreads=1 -XX:ZOldGC...

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

  Implement nested ICacheInvalidationContext

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/4b04496f..b9380fd8

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

  Stats: 402 lines in 27 files changed: 162 ins; 167 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/28328.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328

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

From xpeng at openjdk.org  Fri Dec  5 18:19:39 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 5 Dec 2025 18:19:39 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v5]
In-Reply-To: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
Message-ID: <xrch-EcEAUE5su4cu7YW80GwoAwoQ9WWeJbLGs0fyqg=.3ec5e062-b1a2-497f-9478-1715ae3db4cf@github.com>

> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
> 
> It is caused by the behavior change from follow code:
> 
> Original:
> 
>   if (ShenandoahSATBBarrier) {
>     T* array = dst;
>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>     if (is_old_marking) {
>       // Generational, old marking
>       assert(_heap->mode()->is_generational(), "Invariant");
>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (_heap->mode()->is_generational()) {
>       // Generational, young marking
>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>       // Non-generational, marking
>       arraycopy_work<T, false, false, true>(array, count);
>     }
>   }
> 
> New:
> 
>   if (ShenandoahSATBBarrier) {
>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>       arraycopy_work<T, false, false, true>(dst, count);
>     }
>   }
> 
> 
> 
> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
> - [x] GHA

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Add include header shenandoahOldGeneration.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28669/files
  - new: https://git.openjdk.org/jdk/pull/28669/files/53316bd3..49ea3c93

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

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

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

From btaylor at openjdk.org  Fri Dec  5 18:50:41 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Fri, 5 Dec 2025 18:50:41 GMT
Subject: RFR: 8352914: Shenandoah: Change definition of ShenandoahSharedValue
 to int32_t to leverage platform atomics
Message-ID: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>

The `STATIC_ASSERT` below this typedef appears to be out of date. 

The barriers check thread local copy of gc state, which is stored in `ShenandoahThreadLocalData::_gc_state`  and is type `char`, so the size requirement described by the assert is maintained even after this change.

Change passes all tier1 tests locally when run with Shenandoah GC.

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

Commit messages:
 - 8352914: Shenandoah: Change definition of ShenandoahSharedValue to int32_t to leverage platform atomics

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

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

From wkemper at openjdk.org  Fri Dec  5 18:53:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 5 Dec 2025 18:53:37 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
Message-ID: <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>

> In some cases, the control thread may fail to observe an allocation failure. This results in the thread which failed to allocate waiting forever for the control thread to run a cycle. Depending on which thread fails to allocate, the process may not make progress.

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

  Set requested gc cause under a lock when allocation fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28665/files
  - new: https://git.openjdk.org/jdk/pull/28665/files/89af1701..1081f21e

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

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

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

From wkemper at openjdk.org  Fri Dec  5 18:53:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 5 Dec 2025 18:53:37 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
Message-ID: <lEz_sMnMND0kngc357XW-6ttuf3d8XpIzFRg3dhku7o=.191a1c01-3b76-4f5a-92d9-d009f700993b@github.com>

On Fri, 5 Dec 2025 18:50:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> In some cases, the control thread may fail to observe an allocation failure. This results in the thread which failed to allocate waiting forever for the control thread to run a cycle. Depending on which thread fails to allocate, the process may not make progress.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set requested gc cause under a lock when allocation fails

src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp line 145:

> 143:   // Notifies the control thread, but does not update the requested cause or generation.
> 144:   // The overloaded variant should be used when the _control_lock is already held.
> 145:   void notify_cancellation(GCCause::Cause cause);

These methods were the root cause here. `ShenandoahHeap::_canceled_gc` is read/written atomically, but `ShenandoahGenerationalControlThread::_requested_gc_cause` is read/written under a lock. These `notify_cancellation` methods did _not_ update `_requested_gc_cause` at all. So, in the failure I observed we had:
1. Control thread finishes cycle and sees no cancellation is requested (no lock used).
2. Mutator thread fails allocation, cancels GC (again, no lock used), and does _not_ change `_requested_gc_cause`.
3. Control thread takes `_control_lock` and checks `_requested_gc_cause` and sees  `_no_gc`  (because `notify_cancellation` didn't change it) and `waits` forever now.


The fix here is to replace `notify_cancellation` with `notify_control_thread` which serializes updates to `_requested_gc_cause` under  `_control_lock`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28665#discussion_r2593632599

From wkemper at openjdk.org  Fri Dec  5 19:04:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 5 Dec 2025 19:04:56 GMT
Subject: RFR: 8352914: Shenandoah: Change definition of
 ShenandoahSharedValue to int32_t to leverage platform atomics
In-Reply-To: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
References: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
Message-ID: <EgzDZq64dYWHOwWAJx37PsMbj5vVqjmyLslD_pdg_w4=.de249f2b-4372-4c3c-8e34-146cf354b14f@github.com>

On Fri, 5 Dec 2025 18:44:08 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The `STATIC_ASSERT` below this typedef appears to be out of date. 
> 
> The barriers check thread local copy of gc state, which is stored in `ShenandoahThreadLocalData::_gc_state`  and is type `char`, so the size requirement described by the assert is maintained even after this change.
> 
> Change passes all tier1 tests locally when run with Shenandoah GC.

Marked as reviewed by wkemper (Reviewer).

This looks good to me, but would appreciate another reviewer.

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

PR Review: https://git.openjdk.org/jdk/pull/28681#pullrequestreview-3546051530
PR Comment: https://git.openjdk.org/jdk/pull/28681#issuecomment-3618172121

From kdnilsen at openjdk.org  Fri Dec  5 19:21:56 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 5 Dec 2025 19:21:56 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
Message-ID: <iBLdrpGWeLJexhbCExrnoJQtSuo6_kL9WHW1OD767kA=.66c77bce-877e-469b-87b3-c1661e7cad1c@github.com>

On Fri, 5 Dec 2025 18:53:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> In some cases, the control thread may fail to observe an allocation failure. This results in the thread which failed to allocate waiting forever for the control thread to run a cycle. Depending on which thread fails to allocate, the process may not make progress.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set requested gc cause under a lock when allocation fails

Thanks for diligent testing and analysis.  Subtle code here.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28665#pullrequestreview-3546110509

From kdnilsen at openjdk.org  Fri Dec  5 19:36:56 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 5 Dec 2025 19:36:56 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect [v3]
In-Reply-To: <nDhDGPSvzovYIsAP0jKr311TFj72ZzxR72UkkcofcVk=.cfd87dcc-1f74-4445-9be9-4f3ae1fbc478@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
 <nDhDGPSvzovYIsAP0jKr311TFj72ZzxR72UkkcofcVk=.cfd87dcc-1f74-4445-9be9-4f3ae1fbc478@github.com>
Message-ID: <KTbfuDFNvt67B8JT7qca1auyuZn_dfDRhmvOsrE9uAc=.a4fec091-b4e7-4f19-9b9d-aa3e0ee09438@github.com>

On Thu, 4 Dec 2025 02:19:32 GMT, Rui Li <duke at openjdk.org> wrote:

>> Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 
>> 
>> Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:
>> 
>> 
>> available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
>> soft_tail = Xmx - soft_max
>> if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 
>> 
>> 
>> The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.
>> 
>> 
>> Suggested fix: when deciding when to trigger gc, use logic similar to below:
>> 
>> mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
>> available = mutator_soft_capacity - used;
>> if (available < mutator_soft_capacity) // trigger gc
>> ``` 
>> 
>> -------
>> This change also improved gc logging:
>> 
>> Before:
>> 
>> [6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
>> [6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
>> external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B
>> 
>> 
>> After:
>> 
>> [8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
>> [8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
>> 1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
>> 1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
>> 122, Reserved: 102M, Max free available in a single region: 1024K;
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused freeset includes

Changes requested by kdnilsen (Committer).

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

> 938: 
> 939: size_t ShenandoahGeneration::soft_available_exclude_evac_reserve() const {
> 940:   size_t result = available(ShenandoahHeap::heap()->soft_max_capacity() * (100.0 - ShenandoahEvacReserve) / 100);

I'm a little uncomfortable with this approach.  It's mostly a question of how we name it.  The evac reserve is not always this value.  In particular, we may shrink the young evac reserves after we have selected the cset.  Also of concern is that if someone invokes this function on old_generation(), it looks like they'll get a bogus (not meaningful) value.

I think I'd be more comfortable with naming this to something like "mutator_available_when_gc_is_idle()".  If we keep it virtual, then OldGeneration should override with "assert(false, "Not relevant to old generation")

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

PR Review: https://git.openjdk.org/jdk/pull/28622#pullrequestreview-3546162874
PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2593766590

From wkemper at openjdk.org  Fri Dec  5 20:02:57 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 5 Dec 2025 20:02:57 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v5]
In-Reply-To: <xrch-EcEAUE5su4cu7YW80GwoAwoQ9WWeJbLGs0fyqg=.3ec5e062-b1a2-497f-9478-1715ae3db4cf@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <xrch-EcEAUE5su4cu7YW80GwoAwoQ9WWeJbLGs0fyqg=.3ec5e062-b1a2-497f-9478-1715ae3db4cf@github.com>
Message-ID: <0_7ZOhkCLi17a3aMtxAoV_6hfr9FzZPyto3uOeBqODw=.95f213af-ec8b-4ca3-82a0-c0c95e30ad6d@github.com>

On Fri, 5 Dec 2025 18:19:39 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add include header shenandoahOldGeneration.hpp

The issue, as I understand it, is that mutators are racing with the concurrent remembered set scan. If a mutator changes a pointer covered by a dirty card, it could prevent the remembered set scan from tracing the original object that was reachable at the beginning of marking. Since we may not be marking old, we cannot rely on the TAMS for objects in old regions and must unconditionally enqueue all of the overwritten pointers in the old array. Should we only do this when young marking is in progress? Perhaps we should have a version of `arraycopy_work` that only enqueues young pointers here?

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

PR Review: https://git.openjdk.org/jdk/pull/28669#pullrequestreview-3546247628

From xpeng at openjdk.org  Fri Dec  5 23:01:57 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 5 Dec 2025 23:01:57 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v5]
In-Reply-To: <0_7ZOhkCLi17a3aMtxAoV_6hfr9FzZPyto3uOeBqODw=.95f213af-ec8b-4ca3-82a0-c0c95e30ad6d@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <xrch-EcEAUE5su4cu7YW80GwoAwoQ9WWeJbLGs0fyqg=.3ec5e062-b1a2-497f-9478-1715ae3db4cf@github.com>
 <0_7ZOhkCLi17a3aMtxAoV_6hfr9FzZPyto3uOeBqODw=.95f213af-ec8b-4ca3-82a0-c0c95e30ad6d@github.com>
Message-ID: <fnf1fun2guKjaHoAkOUNtYzxv2pCaUtAasxBAYBoPmQ=.ff861229-644e-492f-9464-126cb5dd7c14@github.com>

On Fri, 5 Dec 2025 20:00:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The issue, as I understand it, is that mutators are racing with the concurrent remembered set scan. If a mutator changes a pointer covered by a dirty card, it could prevent the remembered set scan from tracing the original object that was reachable at the beginning of marking. Since we may not be marking old, we cannot rely on the TAMS for objects in old regions and must unconditionally enqueue all of the overwritten pointers in the old array. Should we only do this when young marking is in progress? Perhaps we should have a version of `arraycopy_work` that only enqueues young pointers here?

I don't think it is related the any racing on remembered set, I got some GC logs from which I think we may know how it actually happens.


[15.653s][info][gc,start       ] GC(188) Pause Full
...
[15.763s][info][gc             ] GC(188) Pause Full 913M->707M(1024M) 109.213ms
[15.767s][info][gc,ergo        ] GC(189) Start GC cycle (Young)
...
[15.802s][info][gc             ] GC(189) Concurrent reset after collect (Young) 1.160ms
[15.802s][info][gc,ergo        ] GC(189) At end of Interrupted Concurrent Young GC: Young generation used: 874M, used regions: 874M, humongous waste: 7066K, soft capacity: 1024M, max capacity: 1022M, available: 99071K
[15.802s][info][gc,ergo        ] GC(189) At end of Interrupted Concurrent Young GC: Old generation used: 1273K, used regions: 1536K, humongous waste: 0B, soft capacity: 1024M, max capacity: 1536K, available: 262K
[15.803s][info][gc,metaspace   ] GC(189) Metaspace: 759K(960K)->759K(960K) NonClass: 721K(832K)->721K(832K) Class: 38K(128K)->38K(128K)
[15.803s][info][gc             ] Trigger (Young): Handle Allocation Failure
[15.803s][info][gc,start       ] GC(190) Pause Full
[15.803s][info][gc,task        ] GC(190) Using 8 of 8 workers for full gc
[15.803s][info][gc,phases,start] GC(190) Phase 1: Mark live objects
[15.806s][info][gc,ref         ] GC(190) Clearing All SoftReferences
<crash happend in full GC) 

1.  188 was a full GC, after 188, all TAMS is reset to bottom in the ShenandoahPostCompactClosure, including all old regions. 
2. 189 was a concurrent young GC, there was array copy barrier executed for an array stored in old, but given TAMS is at the bottom as a result of 188 full GC, the was a no-op due to the bug.
3. 189 finished making, claiming the garbage, but because of the no-op of array copy barrier, the copy was not marked live and was reclaimed.
4. Allocation failure cancelled 189 and escalated to full GC again, but now we have corrupted heap and VM is going to crash.

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

PR Comment: https://git.openjdk.org/jdk/pull/28669#issuecomment-3618896157

From ysr at openjdk.org  Fri Dec  5 23:22:56 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 5 Dec 2025 23:22:56 GMT
Subject: RFR: 8352914: Shenandoah: Change definition of
 ShenandoahSharedValue to int32_t to leverage platform atomics
In-Reply-To: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
References: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
Message-ID: <IdudSxnQiogWKx37i3DS_HKo6ko0uPmYShoYCqzYkqQ=.a53ef80f-4740-4915-985a-01962d739e57@github.com>

On Fri, 5 Dec 2025 18:44:08 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The `STATIC_ASSERT` below this typedef appears to be out of date. 
> 
> The barriers check thread local copy of gc state, which is stored in `ShenandoahThreadLocalData::_gc_state`  and is type `char`, so the size requirement described by the assert is maintained even after this change.
> 
> Change passes all tier1 tests locally when run with Shenandoah GC.

Any comparative performance numbers?

?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28681#pullrequestreview-3546716696

From wkemper at openjdk.org  Fri Dec  5 23:23:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 5 Dec 2025 23:23:00 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v5]
In-Reply-To: <xrch-EcEAUE5su4cu7YW80GwoAwoQ9WWeJbLGs0fyqg=.3ec5e062-b1a2-497f-9478-1715ae3db4cf@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <xrch-EcEAUE5su4cu7YW80GwoAwoQ9WWeJbLGs0fyqg=.3ec5e062-b1a2-497f-9478-1715ae3db4cf@github.com>
Message-ID: <VvOmUdH2yqLJOE40JTqpZY8FmFuKV2knNG31DN5duXQ=.1acd4b3e-4282-43ad-9d8c-c436a520b8a5@github.com>

On Fri, 5 Dec 2025 18:19:39 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add include header shenandoahOldGeneration.hpp

At step 2, we have an element in the old array pointing to young, correct? Why is it not represented in the remembered set at the beginning of young mark? If it is because the old -> young pointer was created _after_ init mark, then the young pointer was either reachable when mark started, or it was created after mark started. Either way, the young pointer should have been found without this SATB modification. Unless, it was in the remembered set, but it didn't get scanned because a mutator modified it before it was scanned.

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

PR Comment: https://git.openjdk.org/jdk/pull/28669#issuecomment-3618939846

From xpeng at openjdk.org  Fri Dec  5 23:34:56 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 5 Dec 2025 23:34:56 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v5]
In-Reply-To: <VvOmUdH2yqLJOE40JTqpZY8FmFuKV2knNG31DN5duXQ=.1acd4b3e-4282-43ad-9d8c-c436a520b8a5@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <xrch-EcEAUE5su4cu7YW80GwoAwoQ9WWeJbLGs0fyqg=.3ec5e062-b1a2-497f-9478-1715ae3db4cf@github.com>
 <VvOmUdH2yqLJOE40JTqpZY8FmFuKV2knNG31DN5duXQ=.1acd4b3e-4282-43ad-9d8c-c436a520b8a5@github.com>
Message-ID: <8yfYsnqygCX37e1fTQOGMs-MRDjVrgmDX-pp799MDfk=.35732036-5d3a-4cc6-ad4e-872e099b6ebf@github.com>

On Fri, 5 Dec 2025 23:19:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> At step 2, we have an element in the old array pointing to young, correct? Why is it not represented in the remembered set at the beginning of young mark? If it is because the old -> young pointer was created _after_ init mark, then the young pointer was either reachable when mark started, or it was created after mark started. Either way, the young pointer should have been found without this SATB modification. Unless, it was in the remembered set, but it didn't get scanned because a mutator modified it before it was scanned.

array copy involves two array object, src and dst. The dst array is an old array, the src may not be an old, it could be young.

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

PR Comment: https://git.openjdk.org/jdk/pull/28669#issuecomment-3618958253

From wkemper at openjdk.org  Sat Dec  6 00:52:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 6 Dec 2025 00:52:01 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v5]
In-Reply-To: <xrch-EcEAUE5su4cu7YW80GwoAwoQ9WWeJbLGs0fyqg=.3ec5e062-b1a2-497f-9478-1715ae3db4cf@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <xrch-EcEAUE5su4cu7YW80GwoAwoQ9WWeJbLGs0fyqg=.3ec5e062-b1a2-497f-9478-1715ae3db4cf@github.com>
Message-ID: <m8OkZgius283jpsz_B_Q3_u_sr70msL8bTXCBQSjnSY=.f77e7e79-9118-4575-a4c1-af5d4cf805c3@github.com>

On Fri, 5 Dec 2025 18:19:39 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add include header shenandoahOldGeneration.hpp

We talked offline. The assertion must be weakened to account for dirty write cards because the young pointer could be put in the old array _after_ init mark. We cannot expect the read card to be dirty in this case.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28669#pullrequestreview-3546805335

From fandreuzzi at openjdk.org  Sun Dec  7 09:59:32 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sun, 7 Dec 2025 09:59:32 GMT
Subject: RFR: 8367541: Parallel: Make young and old generation fields nonstatic
 in ParallelScavengeHeap
Message-ID: <MysZrmjewa5TXfkRIQskjmdjO7KmIzl-H4uxmosegug=.5f59f764-7707-4de0-bc0d-89bf566d0786@github.com>

Young and old generation are part of a heap, so they should be non-static.

Passes tier1 and tier2 (fastdebug).

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

Commit messages:
 - make non static

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

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

From dyama at openjdk.org  Sun Dec  7 15:36:52 2025
From: dyama at openjdk.org (Daisuke Yamazaki)
Date: Sun, 7 Dec 2025 15:36:52 GMT
Subject: RFR: 8372949: ClassWriter.writeClassAttributes() can throw NPE
Message-ID: <SnAYnVLAYBVmPd9dLOU0ZC1VZ0Z4UdMifvtbkXrTLag=.67785903-d9b4-46f1-9c3b-e57623472e6c@github.com>

Hello maintainers,

This change prevents a possible NPE in [`ClassWriter.writeClassWttributes()`](https://github.com/openjdk/jdk/blob/5f083abafc7abfaa46ddd053668cdfbfd2ad8a87/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java#L891).
[`ConstantPool.getBootstrapMethodAt()`](https://github.com/openjdk/jdk/blob/5f083abafc7abfaa46ddd053668cdfbfd2ad8a87/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java#L479) now returns an empty array instead of `null` when no bootstrap methods are available.

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

Commit messages:
 - 8372949: Prevent NPE in getBootstrapMethodAt by returning an empty array for null offsets or bootstrap methods

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

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

From kdnilsen at openjdk.org  Sun Dec  7 17:54:24 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 7 Dec 2025 17:54:24 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth heuristics
Message-ID: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>

When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.

When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.

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

Commit messages:
 - make old evac ratio adaptive
 - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
 - change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
 - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
 - Adjust test for new defaults
 - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
 - Change secondary old trigger to be percent of young-gen heap size
 - add trigger for percent of heap growth

Changes: https://git.openjdk.org/jdk/pull/28561/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28561&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373225
  Stats: 92 lines in 9 files changed: 74 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/28561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28561/head:pull/28561

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

From kdnilsen at openjdk.org  Sun Dec  7 17:54:24 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 7 Dec 2025 17:54:24 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics
In-Reply-To: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
Message-ID: <UNDVsRB2IA0zMkhz_l8n68ywUoyKVtKJcXANjdLA1Y8=.ababc876-3a60-447f-9d71-035f79dcca4d@github.com>

On Sat, 29 Nov 2025 01:10:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
> 
> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.

The benefits of this PR are demonstrated on an Extremem workload.  Comparisons with master are highighted in this spreadsheet:

<img width="2187" height="392" alt="image" src="https://github.com/user-attachments/assets/49935994-7a94-4ace-bc29-7a9e25b32299" />

Highlights:
1. Far fewer old GCs, with slight increase in young GCs (74.45% improvement)
2. Since old GCs are much more costly than young GCs, 4.5% improvement in CPU utilization.
3. Latencies improved across all percentiles (from small increase of 0.3% at p50 to significant increase of 51.2% at p99.999)

The workload is configured as follows:

               ~/github/jdk.11-17-2025/build/linux-x86_64-server-release/images/jdk/bin/java \
                -XX:+UnlockExperimentalVMOptions \
                -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xms8g -Xmx8g \
                -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \
                -XX:ShenandoahMinFreeThreshold=5 \
                -XX:ShenandoahFullGCThreshold=1024 \
                -Xlog:"gc*=info,ergo" \
                -Xlog:safepoint=trace -Xlog:safepoint=debug -Xlog:safepoint=info \
                -XX:+UnlockDiagnosticVMOptions \
                -jar ~/github/heapothesys/Extremem/src/main/java/extremem.jar \
                -dInitializationDelay=45s \
                -dDictionarySize=3000000 \
                -dNumCustomers=300000 \
                -dNumProducts=60000 \
                -dCustomerThreads=750 \
                -dCustomerPeriod=1600ms \
                -dCustomerThinkTime=300ms \
                -dKeywordSearchCount=4 \
                -dServerThreads=5 \
                -dServerPeriod=1s \
                -dProductNameLength=10 \
                -dBrowsingHistoryQueueCount=5 \
                -dSalesTransactionQueueCount=5 \
                -dProductDescriptionLength=32 \
                -dProductReplacementPeriod=10s \
                -dProductReplacementCount=10000 \
                -dCustomerReplacementPeriod=5s \
                -dCustomerReplacementCount=1000 \
                -dBrowsingExpiration=1m \
                -dPhasedUpdates=true \
                -dPhasedUpdateInterval=30s \
                -dSimulationDuration=25m \
                -dResponseTimeMeasurements=100000 \
                >$t.genshen.reproducer.baseline-8g.out 2>$t.genshen.reproducer.baseline-8g.err &
            job_pid=$!
            max_rss_kb=0
            for s in {1..99}
            do
                sleep 15
                rss_kb=$(ps -o rss= -p $job_pid)
                if (( $rss_kb > $max_rss_kb ))
                then
                    max_rss_kb=$rss_kb
                fi
            done
            rss_mb=$((max_rss_kb / 1024))
            cpu_percent=$(ps -o cputime -o etime -p $job_pid)
            wait $job_pid
            echo "RSS: $rss_mb MB" >>$t.genshen.reproducer.baseline-8g.out 2>>$t.genshen.reproducer.share-collector-reserves.err
            echo "$cpu_percent" >>$t.genshen.reproducer.baseline-8g.out 2>>$t.genshen.reproducer.share-collector-reserves.err
            gzip $t.genshen.reproducer.baseline-8g.out $t.genshen.reproducer.baseline-8g.err

Note that this PR causes us to operate closer to the edge of the operating envelope.  In more aggressively provisioned configurations (same workload in smaller heap, for example), we see some regression in latencies compared to tip.  This results because of increased numbers of degenerated GCs which result from starvation of mixed evacuations.  This PR causes us to do fewer old GCs, but each old GC is expected to work more efficiently.  We expect these regressions to be mitigated by other PRs that are currently under development and review, including:
1. Sharing of collector reserves between young and old
2. Accelerated triggers
3. Surging of GC workers
4. Adaptive old-evac ratio

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

PR Comment: https://git.openjdk.org/jdk/pull/28561#issuecomment-3622610260
PR Comment: https://git.openjdk.org/jdk/pull/28561#issuecomment-3622625901

From xpeng at openjdk.org  Sun Dec  7 20:34:13 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Sun, 7 Dec 2025 20:34:13 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be done
 unconditionally by arraycopy_marking if the array is in an old region [v6]
In-Reply-To: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
Message-ID: <aMH6O3gzGJRNEM9frdi-uAgEuhHxamRf8Btu6NEI1SY=.f502889f-136c-412e-84fd-b311c69a2321@github.com>

> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
> 
> It is caused by the behavior change from follow code:
> 
> Original:
> 
>   if (ShenandoahSATBBarrier) {
>     T* array = dst;
>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>     if (is_old_marking) {
>       // Generational, old marking
>       assert(_heap->mode()->is_generational(), "Invariant");
>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (_heap->mode()->is_generational()) {
>       // Generational, young marking
>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>       // Non-generational, marking
>       arraycopy_work<T, false, false, true>(array, count);
>     }
>   }
> 
> New:
> 
>   if (ShenandoahSATBBarrier) {
>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>       arraycopy_work<T, false, false, true>(dst, count);
>     }
>   }
> 
> 
> 
> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS, arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
> - [x] GHA

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  enqueue objects stored in old array at ShenandoahSATBBarrier when concurrent young marking is in progress

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28669/files
  - new: https://git.openjdk.org/jdk/pull/28669/files/49ea3c93..c649cf2b

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

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

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

From iwalulya at openjdk.org  Mon Dec  8 09:09:15 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 8 Dec 2025 09:09:15 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder [v3]
In-Reply-To: <autgJQmEuJ3lQkJ1e_lATd5QU__3UEJ1uOZaoaew-8I=.70b8f1cf-9dd4-4254-9938-be5918949893@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
 <autgJQmEuJ3lQkJ1e_lATd5QU__3UEJ1uOZaoaew-8I=.70b8f1cf-9dd4-4254-9938-be5918949893@github.com>
Message-ID: <ed2ClpH8ZrZcLZU-OzK_PnPOGHmO_GhallpUsBEBkcg=.446285c1-bf2f-4c83-b143-d5c0d7de55e8@github.com>

On Wed, 3 Dec 2025 14:38:57 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> 
>> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> 2. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected"). So, test is split into separate sections pertaining to GC requirements. @requires now has corresponding GC flag condition.
>> 3. Removal of WhiteBox dependency and few cleanups.
>> 
>> Testing:
>> HS Tiers 1 and 2 
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test split into sections

Looks good!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28508#pullrequestreview-3550922348

From iwalulya at openjdk.org  Mon Dec  8 10:18:03 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 8 Dec 2025 10:18:03 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
 <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
Message-ID: <_YMYHK8dlywpVNFeGmTjguc9GQPCgHOUDF6ntFIOGuY=.3edee4fd-8548-46e8-9eac-7698797007a8@github.com>

On Tue, 2 Dec 2025 08:56:28 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Summary of change:
>> 
>> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
>> 2. Test is split into separate sections pertaining to GC requirements. @requires now has corresponding GC flag condition.
>> 3. Addition of ZGC to list of parallel collectors
>> 
>> Testing:
>> HS Tiers 1 and 2
>> Ran with all flag combinations in CI
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separating test sections

Looks good!

Nit:

test/hotspot/jtreg/gc/arguments/TestParallelGCThreads.java line 156:

> 154:   }
> 155: 
> 156:   private static void testMaxValue() throws Exception {

Could be helpful to have a comment on why we use SerialGC for this test. However, that is pre-existing, so you can ignore.

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28566#pullrequestreview-3551226661
PR Review Comment: https://git.openjdk.org/jdk/pull/28566#discussion_r2597952886

From rsunderbabu at openjdk.org  Mon Dec  8 10:25:57 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Mon, 8 Dec 2025 10:25:57 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <MxqaT_41YJUaCWgRUkh-48HG9yp1p7Ez__EOqr6oUR4=.7cb96378-16e2-431c-845f-d0fb7edb88c0@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
 <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
 <MxqaT_41YJUaCWgRUkh-48HG9yp1p7Ez__EOqr6oUR4=.7cb96378-16e2-431c-845f-d0fb7edb88c0@github.com>
Message-ID: <los0qdyL_ceOpIgk3uyTL-sRd1X_X-n8mPNn7R5Rmxk=.14c164ca-4c07-47e4-998c-0ca4aba5d645@github.com>

On Tue, 2 Dec 2025 13:12:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   separating test sections
>
> Could you update the summary of this PR to reflect the final change? Could you also indicate that you have rerun the testing with the latest changes?

Thanks @stefank and @walulyai for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28566#issuecomment-3626146172

From rsunderbabu at openjdk.org  Mon Dec  8 10:25:59 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Mon, 8 Dec 2025 10:25:59 GMT
Subject: RFR: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <_YMYHK8dlywpVNFeGmTjguc9GQPCgHOUDF6ntFIOGuY=.3edee4fd-8548-46e8-9eac-7698797007a8@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
 <u_l21BJFEoRgBPpo93K3e8LYdkObIthpsO_9em2ISlU=.13010531-a540-47f6-b6db-b9acdb09b6ec@github.com>
 <_YMYHK8dlywpVNFeGmTjguc9GQPCgHOUDF6ntFIOGuY=.3edee4fd-8548-46e8-9eac-7698797007a8@github.com>
Message-ID: <aGnKs-5YVIXE1t-aM9x1BOx4oC6ALlUQ5e6bJP225wE=.f5b16998-6112-483e-8e67-1b60eed58e4c@github.com>

On Mon, 8 Dec 2025 10:14:22 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   separating test sections
>
> test/hotspot/jtreg/gc/arguments/TestParallelGCThreads.java line 156:
> 
>> 154:   }
>> 155: 
>> 156:   private static void testMaxValue() throws Exception {
> 
> Could be helpful to have a comment on why we use SerialGC for this test. However, that is pre-existing, so you can ignore.

I prefer leaving it as it is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28566#discussion_r2597989316

From rsunderbabu at openjdk.org  Mon Dec  8 10:26:57 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Mon, 8 Dec 2025 10:26:57 GMT
Subject: RFR: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder [v2]
In-Reply-To: <9-yPj5BYtvHE5AU4P9qJw1x__I7u_SV9GQHcAl4JXRk=.4ce1f46a-1591-44b0-94e4-bdb29a460d53@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
 <IUfN20CkPlSwyTdMJq8oQA3JsYb9oGUfp6LUHk3zGEc=.4dc5d479-ca46-4346-9537-ed610ce2082a@github.com>
 <9-yPj5BYtvHE5AU4P9qJw1x__I7u_SV9GQHcAl4JXRk=.4ce1f46a-1591-44b0-94e4-bdb29a460d53@github.com>
Message-ID: <5pv48EW3yY5pILzSgzpsSNF8P-U08ffcebBWakUTlCk=.c4287eba-c00b-48a0-beb7-3d8be00b39fe@github.com>

On Wed, 3 Dec 2025 09:28:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing the requires condition
>
>> I guess you mean https://github.com/openjdk/jdk/pull/28566. I will restructure this test along those lines.
> 
> Yes, you are right.

Thanks @stefank and @walulyai for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28508#issuecomment-3626150054

From ayang at openjdk.org  Mon Dec  8 11:01:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 11:01:58 GMT
Subject: RFR: 8367541: Parallel: Make young and old generation fields
 nonstatic in ParallelScavengeHeap
In-Reply-To: <MysZrmjewa5TXfkRIQskjmdjO7KmIzl-H4uxmosegug=.5f59f764-7707-4de0-bc0d-89bf566d0786@github.com>
References: <MysZrmjewa5TXfkRIQskjmdjO7KmIzl-H4uxmosegug=.5f59f764-7707-4de0-bc0d-89bf566d0786@github.com>
Message-ID: <MIH28u3cNC8JXyqebsIFwdVGqObT0Z0INXORktjCt4c=.82c81c24-2668-4e5b-a9a2-cd9feb476362@github.com>

On Sun, 7 Dec 2025 09:52:33 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Young and old generation are part of a heap, so they should be non-static.
> 
> Passes tier1 and tier2 (fastdebug).

Looks good. Collectively reviewed at UU.

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28689#pullrequestreview-3551442232

From fandreuzzi at openjdk.org  Mon Dec  8 11:49:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 8 Dec 2025 11:49:05 GMT
Subject: RFR: 8367541: Parallel: Make young and old generation fields
 nonstatic in ParallelScavengeHeap
In-Reply-To: <MIH28u3cNC8JXyqebsIFwdVGqObT0Z0INXORktjCt4c=.82c81c24-2668-4e5b-a9a2-cd9feb476362@github.com>
References: <MysZrmjewa5TXfkRIQskjmdjO7KmIzl-H4uxmosegug=.5f59f764-7707-4de0-bc0d-89bf566d0786@github.com>
 <MIH28u3cNC8JXyqebsIFwdVGqObT0Z0INXORktjCt4c=.82c81c24-2668-4e5b-a9a2-cd9feb476362@github.com>
Message-ID: <k2TMFi_oMFB8toBJlsswbLzaIY1d17KYZYXL2bY6jmg=.6fb89c2e-0bde-40f7-a808-0ac49000e163@github.com>

On Mon, 8 Dec 2025 10:59:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Young and old generation are part of a heap, so they should be non-static.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Looks good. Collectively reviewed at UU.

Thanks for the review @albertnetymk.

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

PR Comment: https://git.openjdk.org/jdk/pull/28689#issuecomment-3626508071

From fandreuzzi at openjdk.org  Mon Dec  8 11:49:06 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 8 Dec 2025 11:49:06 GMT
Subject: Integrated: 8367541: Parallel: Make young and old generation fields
 nonstatic in ParallelScavengeHeap
In-Reply-To: <MysZrmjewa5TXfkRIQskjmdjO7KmIzl-H4uxmosegug=.5f59f764-7707-4de0-bc0d-89bf566d0786@github.com>
References: <MysZrmjewa5TXfkRIQskjmdjO7KmIzl-H4uxmosegug=.5f59f764-7707-4de0-bc0d-89bf566d0786@github.com>
Message-ID: <IqeKYfg42NzZSuIGufzaZcdayj_Oky0mQuHwlhR_gg4=.d8ec2d26-c459-44b5-bb76-dec8ee220adc@github.com>

On Sun, 7 Dec 2025 09:52:33 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Young and old generation are part of a heap, so they should be non-static.
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: a6594794
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6594794839807d56434d6f28fe3d581fb1e36c0
Stats:     9 lines in 4 files changed: 0 ins; 2 del; 7 mod

8367541: Parallel: Make young and old generation fields nonstatic in ParallelScavengeHeap

Reviewed-by: ayang

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

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

From ayang at openjdk.org  Mon Dec  8 14:21:54 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 14:21:54 GMT
Subject: RFR: 8373087: Parallel: Rename PSGenerationPool to
 PSOldGenerationPool [v2]
In-Reply-To: <A5LKur7bF_2SrwlAabNj2T1otfc6neo7zUQhkNkTff0=.93c40608-0167-467e-b1ca-6942f3d09e1d@github.com>
References: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
 <A5LKur7bF_2SrwlAabNj2T1otfc6neo7zUQhkNkTff0=.93c40608-0167-467e-b1ca-6942f3d09e1d@github.com>
Message-ID: <OFqLAtJNJLu5wTC2HWF_xD_bRp0vESpGZ6Oe7aJynZg=.e093e803-c0c1-4778-8a9f-239367be7c92@github.com>

On Thu, 4 Dec 2025 19:39:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial renaming to make it explicit that this class is only for old-gen.
>> 
>> Test: GHA
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28657#issuecomment-3627161167

From ayang at openjdk.org  Mon Dec  8 14:24:31 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 14:24:31 GMT
Subject: Integrated: 8373087: Parallel: Rename PSGenerationPool to
 PSOldGenerationPool
In-Reply-To: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
References: <Kd9MD0rTbMw8wHOBFHfA0YJo_yGNZasbsHoa9_SNWQY=.4349ab9f-8d0a-4cae-a7a7-4b6c4dc86974@github.com>
Message-ID: <3VlImf4IIZFd0nn_1zBd5oMK-KhYr2thSig0z-8ySsc=.355fab10-fd9f-4c87-995e-ba43a2c99186@github.com>

On Thu, 4 Dec 2025 11:01:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial renaming to make it explicit that this class is only for old-gen.
> 
> Test: GHA

This pull request has now been integrated.

Changeset: ed5fc9ad
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed5fc9ad2defb75ea5a68fe6427a591376ce6d6b
Stats:     9 lines in 3 files changed: 0 ins; 0 del; 9 mod

8373087: Parallel: Rename PSGenerationPool to PSOldGenerationPool

Reviewed-by: tschatzl, jsikstro, iwalulya

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

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

From ayang at openjdk.org  Mon Dec  8 14:56:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 14:56:32 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails
Message-ID: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>

[JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.

`TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.

Test: tier1-2

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

Commit messages:
 - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java

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

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

From cjplummer at openjdk.org  Mon Dec  8 15:38:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Dec 2025 15:38:50 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails
In-Reply-To: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
Message-ID: <e6yodTLLlqhJTWJKYVrrLKYu61ilZp3KDxlQyAL7dGo=.489d475a-9f9b-4f14-b5e8-3a28ca55de00@github.com>

On Mon, 8 Dec 2025 14:50:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
> 
> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
> 
> Test: tier1-2

Copyright needs updating. Otherwise it looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/28700#pullrequestreview-3552670288

From wkemper at openjdk.org  Mon Dec  8 15:58:02 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Dec 2025 15:58:02 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v6]
In-Reply-To: <aMH6O3gzGJRNEM9frdi-uAgEuhHxamRf8Btu6NEI1SY=.f502889f-136c-412e-84fd-b311c69a2321@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <aMH6O3gzGJRNEM9frdi-uAgEuhHxamRf8Btu6NEI1SY=.f502889f-136c-412e-84fd-b311c69a2321@github.com>
Message-ID: <LnHK6ftcvWNKoALBP5EbNwhWaqOTVwCWP8YnSkH-WVQ=.c78f9e9f-ae22-4e40-ad96-4c4581c73119@github.com>

On Sun, 7 Dec 2025 20:34:13 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enqueue objects stored in old array at ShenandoahSATBBarrier when concurrent young marking is in progress

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 451:

> 449:   if (ShenandoahSATBBarrier) {
> 450:     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst)) ||
> 451:         (_heap->is_concurrent_young_mark_in_progress() && _heap->heap_region_containing(dst)->is_old())) {

We could also check if Shenandoah is running in generational mode. Even in non-generational mode, we set `YOUNG_MARKING` in gc state.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2599168582

From ayang at openjdk.org  Mon Dec  8 15:58:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 15:58:32 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails [v2]
In-Reply-To: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
Message-ID: <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>

> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
> 
> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
> 
> Test: tier1-2

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28700/files
  - new: https://git.openjdk.org/jdk/pull/28700/files/67c306e4..1f70f90b

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

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

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

From cjplummer at openjdk.org  Mon Dec  8 15:58:32 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Dec 2025 15:58:32 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails [v2]
In-Reply-To: <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
 <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>
Message-ID: <dEQSYNW8WY5nYVN813ptvIxqHdpbWox-VdjG5ppaLZo=.03160ac6-710e-490d-9954-a9cde1557085@github.com>

On Mon, 8 Dec 2025 15:55:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
>> 
>> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
>> 
>> Test: tier1-2
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28700#pullrequestreview-3552769993

From ayang at openjdk.org  Mon Dec  8 16:13:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 16:13:52 GMT
Subject: RFR: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails [v2]
In-Reply-To: <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
 <024bxmuvDcaJ5FB-roAP5cOlCGqamNynNtjoK23nRxI=.d6c8875f-0629-4470-845e-240204fac96f@github.com>
Message-ID: <Djo8YCABVsKCDq1zBzXbL2dghsUQFiazOIAKW4VTeag=.d888aaf4-af74-44cd-8028-58fd1e64a4f8@github.com>

On Mon, 8 Dec 2025 15:58:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
>> 
>> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
>> 
>> Test: tier1-2
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review. Merging now to reduce CI noise.

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

PR Comment: https://git.openjdk.org/jdk/pull/28700#issuecomment-3627760652

From ayang at openjdk.org  Mon Dec  8 16:13:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 16:13:53 GMT
Subject: Integrated: 8373262: Parallel:
 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails
In-Reply-To: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
References: <A3jTnciURrgPHbe6PSfDPK_FiIThoa2ZlRhbT7fe800=.63dfffe0-6c1a-4ed1-991f-716f83fb4c22@github.com>
Message-ID: <5xnAvzMSfARGEbCbhXs5vPoGEKbwX8EIT7D8olpx9hs=.28e899fd-0722-4e3a-bc48-be5fc42eba46@github.com>

On Mon, 8 Dec 2025 14:50:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> [JDK-8367541](https://bugs.openjdk.org/browse/JDK-8367541) changes the fields in `src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp` to be non-static. The corresponding access in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java` should be updated as well.
> 
> `TEST=gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java JTREG_JAVA_OPTIONS=-XX:+UseParallelGC` fails consistently without the fix and passes with the fix.
> 
> Test: tier1-2

This pull request has now been integrated.

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

8373262: Parallel: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails

Reviewed-by: cjplummer

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

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

From wkemper at openjdk.org  Mon Dec  8 16:44:57 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Dec 2025 16:44:57 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics
In-Reply-To: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
Message-ID: <g50NQReQ49atVxRT_voQYiyH2fnZIlbhavT_dGOvgRo=.3e69b820-ec94-4319-a4ee-d03c6fff4c41@github.com>

On Sat, 29 Nov 2025 01:10:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
> 
> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.

Changes requested by wkemper (Reviewer).

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 212:

> 210:   void slide_pinned_regions_to_front();
> 211:   bool all_candidates_are_pinned();
> 212:   void adjust_old_garbage_threshold();

A brief general comment about the algorithm here or in the implementation would be welcome. As I read it, we are lowering the region's garbage threshold as the occupancy in the old generation increases. Lowering the garbage threshold will increase the number of old regions selected for a mixed collection.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 252:

> 250:     (_live_bytes_after_last_mark + ((ShenandoahHeap::heap()->soft_max_capacity() - _live_bytes_after_last_mark)
> 251:                                     * ShenandoahMinOldGenGrowthRemainingHeapPercent / 100.0));
> 252:   size_t result = MIN2(threshold_by_relative_growth, threshold_by_growth_into_percent_remaining);

Are we comparing bytes to a percentage here? Not sure I understand the role of `FRACTIONAL_DENOMINATOR`.

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

PR Review: https://git.openjdk.org/jdk/pull/28561#pullrequestreview-3552965737
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2599302961
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2599331553

From xpeng at openjdk.org  Mon Dec  8 18:05:00 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 18:05:00 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v6]
In-Reply-To: <LnHK6ftcvWNKoALBP5EbNwhWaqOTVwCWP8YnSkH-WVQ=.c78f9e9f-ae22-4e40-ad96-4c4581c73119@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <aMH6O3gzGJRNEM9frdi-uAgEuhHxamRf8Btu6NEI1SY=.f502889f-136c-412e-84fd-b311c69a2321@github.com>
 <LnHK6ftcvWNKoALBP5EbNwhWaqOTVwCWP8YnSkH-WVQ=.c78f9e9f-ae22-4e40-ad96-4c4581c73119@github.com>
Message-ID: <7VQhaVsTX2vUrVDFT8DLdVAFZjhhbentEUo3Fms4MMY=.fb2be599-6ab5-4e5c-bd8c-10840ac1f5c5@github.com>

On Mon, 8 Dec 2025 15:55:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   enqueue objects stored in old array at ShenandoahSATBBarrier when concurrent young marking is in progress
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 451:
> 
>> 449:   if (ShenandoahSATBBarrier) {
>> 450:     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst)) ||
>> 451:         (_heap->is_concurrent_young_mark_in_progress() && _heap->heap_region_containing(dst)->is_old())) {
> 
> We could also check if Shenandoah is running in generational mode. Even in non-generational mode, we set `YOUNG_MARKING` in gc state.

When is_old returns true, it implies Shenandoah is in generational mode, so logically it is not needed to test if is in generational mode, but we may want to test the mode for performance consideration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2599591835

From wkemper at openjdk.org  Mon Dec  8 18:08:49 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Dec 2025 18:08:49 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v12]
In-Reply-To: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
Message-ID: <OOi7XyQOl5bHKAJouT2WtKuXpPpXb0jjefF4gRvrZy8=.6ed7b859-7c75-4369-9b54-d7e6f6007a2a@github.com>

> Notable changes:
> * Improvements to logging
> * More accurate tracking of promotion failures
> * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size)
> * Use census information gathered during mark to size promotion reserves and old generation
> 
> With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results.
> 
> Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks:
> 
> 
> Concurrent Evacuation: 7 improvements, 3 regressions
> ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%)
> ? Worst regression: xalan (+53.7%)
> 
> Concurrent Marking: 15 improvements, 1 regression  
> ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%)
> ? Only regression: serial (+8.9%)
> 
> Concurrent Scan Remembered Set: 7 improvements, 2 regressions
> ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%)
> ? Worst regression: extremem-phased (+52.4%)
> 
> Concurrent Update Refs: 5 improvements, 4 regressions
> ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%)
> ? Worst regression: xalan (+89.4%)

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

 - Fix comments, add back an assertion
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Accommodate behavior of global heuristic
 - Restore missing update for inplace promotion padding
 - Remove reference to adaptive tuning flag
 - Remove commented out assertion
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Adaptive tenuring is no longer optional
   
   We are using age census data to compute promotion reserves. The tenuring threshold may still be fixed by setting the min/max threshold to the same value.
 - Remove bad asserts
 - Don't include tenurable bytes for current cycle in the next cycle
   
   Also remove vestigial promotion potential calculation
 - ... and 69 more: https://git.openjdk.org/jdk/compare/811591c5...e3f22960

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

Changes: https://git.openjdk.org/jdk/pull/27632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=11
  Stats: 398 lines in 11 files changed: 158 ins; 173 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/27632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27632/head:pull/27632

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

From xpeng at openjdk.org  Mon Dec  8 18:09:00 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 18:09:00 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
Message-ID: <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>

> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
> 
> It is caused by the behavior change from follow code:
> 
> Original:
> 
>   if (ShenandoahSATBBarrier) {
>     T* array = dst;
>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>     if (is_old_marking) {
>       // Generational, old marking
>       assert(_heap->mode()->is_generational(), "Invariant");
>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (_heap->mode()->is_generational()) {
>       // Generational, young marking
>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>       // Non-generational, marking
>       arraycopy_work<T, false, false, true>(array, count);
>     }
>   }
> 
> New:
> 
>   if (ShenandoahSATBBarrier) {
>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>       arraycopy_work<T, false, false, true>(dst, count);
>     }
>   }
> 
> 
> 
> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
> - [x] GHA

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Also test is_generational

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28669/files
  - new: https://git.openjdk.org/jdk/pull/28669/files/c649cf2b..225b999d

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

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

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

From wkemper at openjdk.org  Mon Dec  8 18:29:02 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Dec 2025 18:29:02 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
Message-ID: <miL-wRxyB8aNHnFghNsdtAzP3bC7KtwV6jsA0RO_Jm0=.e8e1593a-c162-4141-89d1-bb9137324666@github.com>

On Mon, 8 Dec 2025 18:09:00 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also test is_generational

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28669#pullrequestreview-3553497303

From ayang at openjdk.org  Mon Dec  8 18:56:09 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 18:56:09 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v5]
In-Reply-To: <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>
Message-ID: <XumwHeZ-5oPhHcO7RycRhxA_5pbN0P_kl-d0UZJR1uU=.47c5ce6b-2d6c-42fe-95d8-4767b18361a2@github.com>

On Fri, 5 Dec 2025 11:01:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/serial/serialHeap.cpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28393#issuecomment-3628550209

From ayang at openjdk.org  Mon Dec  8 18:56:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 18:56:10 GMT
Subject: Integrated: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <K_IARQs0fu7O1Fne_BRSbMp1A0q7wk1zWG7LhJ9RKYU=.5090d8d6-a7ef-446b-bd1a-e4927e6d2f76@github.com>

On Wed, 19 Nov 2025 15:39:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

This pull request has now been integrated.

Changeset: d34ef196
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d34ef196c298aa91f8511714cfb04b15ae7fbf0a
Stats:     21 lines in 4 files changed: 19 ins; 2 del; 0 mod

8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed:  assert(left >= right) failed: avoid underflow

Reviewed-by: stefank, tschatzl

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

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

From xpeng at openjdk.org  Mon Dec  8 19:59:08 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 19:59:08 GMT
Subject: RFR: 8373272: Genshen: ShenandoahOldGenerationTest fails after
 JDK-8373056
Message-ID: <eBbU9Nhz4n_44kDdQFTcB-_bUI9v03dEFO8lMPBW0t8=.6b45e880-2e8b-40ff-bafc-71c4997f87ae@github.com>

ShenandoahOldGeneration::configure_plab_for_current_thread has been updated to only handle plab req, which is a behavior change, but ShenandoahOldGenerationTest was not updated to match the behavior change, causing the test to fail.

The two failing unit tests of ShenandoahOldGenerationTest have been removed in this PR since the behavior being verified with them is no longer in configure_plab_for_current_thread, meanwhile one more unit test is added to verify the behavior of `expend_promoted`

### Test
- [x] CONF=macosx-aarch64-server-fastdebug make test TEST=gtest
- [ ] CONF=macosx-aarch64-server-fastdebug make test TEST=hotspot_gc_shenandoah

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

Commit messages:
 - Remove tests and revert the changes to configure_plab_for_current_thread
 - Rework on configure_plab_for_current_thread and the unit test to fix test failures

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

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

From wkemper at openjdk.org  Mon Dec  8 19:59:09 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Dec 2025 19:59:09 GMT
Subject: RFR: 8373272: Genshen: ShenandoahOldGenerationTest fails after
 JDK-8373056
In-Reply-To: <eBbU9Nhz4n_44kDdQFTcB-_bUI9v03dEFO8lMPBW0t8=.6b45e880-2e8b-40ff-bafc-71c4997f87ae@github.com>
References: <eBbU9Nhz4n_44kDdQFTcB-_bUI9v03dEFO8lMPBW0t8=.6b45e880-2e8b-40ff-bafc-71c4997f87ae@github.com>
Message-ID: <wkG_LF9tkRcGF7Stkp_3UcaGXw4Do9MZRS74bnDOHmM=.04482e64-db25-4cd1-8859-b977c229a885@github.com>

On Mon, 8 Dec 2025 19:32:16 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> ShenandoahOldGeneration::configure_plab_for_current_thread has been updated to only handle plab req, which is a behavior change, but ShenandoahOldGenerationTest was not updated to match the behavior change, causing the test to fail.
> 
> The two failing unit tests of ShenandoahOldGenerationTest have been removed in this PR since the behavior being verified with them is no longer in configure_plab_for_current_thread, meanwhile one more unit test is added to verify the behavior of `expend_promoted`
> 
> ### Test
> - [x] CONF=macosx-aarch64-server-fastdebug make test TEST=gtest
> - [ ] CONF=macosx-aarch64-server-fastdebug make test TEST=hotspot_gc_shenandoah

Changes requested by wkemper (Reviewer).

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

> 194: }
> 195: 
> 196: void

I would revert this back to asserting its never called for a shared allocation and delete the test (but keep the new `test_expend_promoted_should_increase_expended`).

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

PR Review: https://git.openjdk.org/jdk/pull/28706#pullrequestreview-3553772130
PR Review Comment: https://git.openjdk.org/jdk/pull/28706#discussion_r2599902076

From xpeng at openjdk.org  Mon Dec  8 19:59:10 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 19:59:10 GMT
Subject: RFR: 8373272: Genshen: ShenandoahOldGenerationTest fails after
 JDK-8373056
In-Reply-To: <wkG_LF9tkRcGF7Stkp_3UcaGXw4Do9MZRS74bnDOHmM=.04482e64-db25-4cd1-8859-b977c229a885@github.com>
References: <eBbU9Nhz4n_44kDdQFTcB-_bUI9v03dEFO8lMPBW0t8=.6b45e880-2e8b-40ff-bafc-71c4997f87ae@github.com>
 <wkG_LF9tkRcGF7Stkp_3UcaGXw4Do9MZRS74bnDOHmM=.04482e64-db25-4cd1-8859-b977c229a885@github.com>
Message-ID: <KBVr-SObM0hhQyLlxzks9klCNKZdcimZHPPcxJSiPuk=.d1fc1cf4-8900-47a3-be20-8d5bee4a58c7@github.com>

On Mon, 8 Dec 2025 19:40:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> ShenandoahOldGeneration::configure_plab_for_current_thread has been updated to only handle plab req, which is a behavior change, but ShenandoahOldGenerationTest was not updated to match the behavior change, causing the test to fail.
>> 
>> The two failing unit tests of ShenandoahOldGenerationTest have been removed in this PR since the behavior being verified with them is no longer in configure_plab_for_current_thread, meanwhile one more unit test is added to verify the behavior of `expend_promoted`
>> 
>> ### Test
>> - [x] CONF=macosx-aarch64-server-fastdebug make test TEST=gtest
>> - [ ] CONF=macosx-aarch64-server-fastdebug make test TEST=hotspot_gc_shenandoah
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 196:
> 
>> 194: }
>> 195: 
>> 196: void
> 
> I would revert this back to asserting its never called for a shared allocation and delete the test (but keep the new `test_expend_promoted_should_increase_expended`).

Thanks, I also prefer this approach.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28706#discussion_r2599931175

From kdnilsen at openjdk.org  Mon Dec  8 20:56:00 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 8 Dec 2025 20:56:00 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
Message-ID: <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>

On Mon, 8 Dec 2025 18:09:00 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also test is_generational

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 450:

> 448:   assert(_heap->is_concurrent_mark_in_progress(), "only during marking");
> 449:   if (ShenandoahSATBBarrier) {
> 450:     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst)) ||

Predicates:
  A: heap->is_concurrent_young_mark_in_progress()
  B: heap->is_concurrent_old_mark_in_progress()
  C: heap->heap_region_containining(dst)->is_old()
  D: !heap->marking_context()->allocated_after_mark_start(dst)

I think the conditions under which we need to call arraycopy_work() are:
(A && C) || (A && D) || (B && C && D)
which could be written:
(A && (C || D)) || (B && C && D)

As written, I think we are also calling arraycopy_work() under certain unnecessary conditions, such as:
(B && C)

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 464:

> 462:             assert(!_heap->is_in_young(obj) ||
> 463:                    card_scan->is_card_dirty(elem_heap_word_ptr) ||
> 464:                    card_scan->is_write_card_dirty(elem_heap_word_ptr),

I believe there is a very slight risk of assertion failure here, which might be so rare that you could just mention the possibility in the "error message" or in a comment associated with this code.

The race is that some other thread could overwrite an an old-gen array element with pointer to young during young marking, and we might see this interesting young pointer before that other thread has had a chance to mark the associated card dirty.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600079828
PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600102116

From kdnilsen at openjdk.org  Mon Dec  8 20:56:01 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 8 Dec 2025 20:56:01 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
 <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
Message-ID: <ZfbROnRYXCf9kH1T5mO2i2luwBnkW4FMZaFRHOhT7to=.647cb5f0-e79b-4445-a0b6-e4f474c55b5f@github.com>

On Mon, 8 Dec 2025 20:45:36 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also test is_generational
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 450:
> 
>> 448:   assert(_heap->is_concurrent_mark_in_progress(), "only during marking");
>> 449:   if (ShenandoahSATBBarrier) {
>> 450:     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst)) ||
> 
> Predicates:
>   A: heap->is_concurrent_young_mark_in_progress()
>   B: heap->is_concurrent_old_mark_in_progress()
>   C: heap->heap_region_containining(dst)->is_old()
>   D: !heap->marking_context()->allocated_after_mark_start(dst)
> 
> I think the conditions under which we need to call arraycopy_work() are:
> (A && C) || (A && D) || (B && C && D)
> which could be written:
> (A && (C || D)) || (B && C && D)
> 
> As written, I think we are also calling arraycopy_work() under certain unnecessary conditions, such as:
> (B && C)

Wondering if the test for is_generational() could be captured in a template parameter. Each invocation that I find with grep already knows whether is_generational.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600093807

From xpeng at openjdk.org  Mon Dec  8 21:14:12 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 21:14:12 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <ZfbROnRYXCf9kH1T5mO2i2luwBnkW4FMZaFRHOhT7to=.647cb5f0-e79b-4445-a0b6-e4f474c55b5f@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
 <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
 <ZfbROnRYXCf9kH1T5mO2i2luwBnkW4FMZaFRHOhT7to=.647cb5f0-e79b-4445-a0b6-e4f474c55b5f@github.com>
Message-ID: <4V8h9n8guTinNiCNYtecwcEKZb4y8zz6Qnwidpc4lC4=.149b8dd2-e5d5-45ad-9f93-12be677a2072@github.com>

On Mon, 8 Dec 2025 20:49:30 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 450:
>> 
>>> 448:   assert(_heap->is_concurrent_mark_in_progress(), "only during marking");
>>> 449:   if (ShenandoahSATBBarrier) {
>>> 450:     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst)) ||
>> 
>> Predicates:
>>   A: heap->is_concurrent_young_mark_in_progress()
>>   B: heap->is_concurrent_old_mark_in_progress()
>>   C: heap->heap_region_containining(dst)->is_old()
>>   D: !heap->marking_context()->allocated_after_mark_start(dst)
>> 
>> I think the conditions under which we need to call arraycopy_work() are:
>> (A && C) || (A && D) || (B && C && D)
>> which could be written:
>> (A && (C || D)) || (B && C && D)
>> 
>> As written, I think we are also calling arraycopy_work() under certain unnecessary conditions, such as:
>> (B && C)
>
> Wondering if the test for is_generational() could be captured in a template parameter. Each invocation that I find with grep already knows whether is_generational.

Thanks to make it so clear, I did similar evaluation and knew we will call arraycopy_work when (B && C) is true, but it shouldn't cause crash from OldGC, we will be more conservative in such case resulting in maybe more live objects.

I'll try to make the tests here more accurate in the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600146192

From xpeng at openjdk.org  Mon Dec  8 21:30:00 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 21:30:00 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
 <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
Message-ID: <KyPIVrhUKUc7t9Bmhe1J6EDal6uGDXnsbXWj4ixX9xQ=.fa6c790e-6224-4192-a973-047a85cd9dd2@github.com>

On Mon, 8 Dec 2025 20:52:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also test is_generational
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 464:
> 
>> 462:             assert(!_heap->is_in_young(obj) ||
>> 463:                    card_scan->is_card_dirty(elem_heap_word_ptr) ||
>> 464:                    card_scan->is_write_card_dirty(elem_heap_word_ptr),
> 
> I believe there is a very slight risk of assertion failure here, which might be so rare that you could just mention the possibility in the "error message" or in a comment associated with this code.
> 
> The race is that some other thread could overwrite an an old-gen array element with pointer to young during young marking, and we might see this interesting young pointer before that other thread has had a chance to mark the associated card dirty.

Yes, it is still possible to fail because during arraycopy, there could be mutators updating objects in the array or also  do arraycopy, they will update the write card at the same time. 

With the better understanding of ShenandoahSATBBarrier and ShenandoahCardBarrier after the discussions, I don't think it make sense to add the these asserts. We are verifying the behavior of ShenandoahCardBarrier in the ShenandoahSATBBarrier code, which is wired and will confuse people when will read the code in the further.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600191941

From xpeng at openjdk.org  Mon Dec  8 21:46:57 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 21:46:57 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <4V8h9n8guTinNiCNYtecwcEKZb4y8zz6Qnwidpc4lC4=.149b8dd2-e5d5-45ad-9f93-12be677a2072@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
 <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
 <ZfbROnRYXCf9kH1T5mO2i2luwBnkW4FMZaFRHOhT7to=.647cb5f0-e79b-4445-a0b6-e4f474c55b5f@github.com>
 <4V8h9n8guTinNiCNYtecwcEKZb4y8zz6Qnwidpc4lC4=.149b8dd2-e5d5-45ad-9f93-12be677a2072@github.com>
Message-ID: <hD4jJ0NaAgU0XNe_UrRzT21CC-F6ctXmDA-t74JXG2o=.3f587de4-8446-436a-8aac-a6148723ed82@github.com>

On Mon, 8 Dec 2025 21:09:31 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Wondering if the test for is_generational() could be captured in a template parameter. Each invocation that I find with grep already knows whether is_generational.
>
> Thanks to make it so clear, I did similar evaluation and knew we will call arraycopy_work when (B && C) is true, but it shouldn't cause crash from OldGC, we will be more conservative in such case resulting in maybe more live objects.
> 
> I'll try to make the tests here more accurate in the PR.

arraycopy_work will be called when (B && C) is true if only A is also true, it is expected and what we wanted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600242973

From wkemper at openjdk.org  Mon Dec  8 21:46:58 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Dec 2025 21:46:58 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <hD4jJ0NaAgU0XNe_UrRzT21CC-F6ctXmDA-t74JXG2o=.3f587de4-8446-436a-8aac-a6148723ed82@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
 <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
 <ZfbROnRYXCf9kH1T5mO2i2luwBnkW4FMZaFRHOhT7to=.647cb5f0-e79b-4445-a0b6-e4f474c55b5f@github.com>
 <4V8h9n8guTinNiCNYtecwcEKZb4y8zz6Qnwidpc4lC4=.149b8dd2-e5d5-45ad-9f93-12be677a2072@github.com>
 <hD4jJ0NaAgU0XNe_UrRzT21CC-F6ctXmDA-t74JXG2o=.3f587de4-8446-436a-8aac-a6148723ed82@github.com>
Message-ID: <iO5qOvEAvEmYjkRf2h0ixQZ9QGe318CMwpD_EPapyFY=.2289094f-2a91-45ae-826b-6bafd6399be5@github.com>

On Mon, 8 Dec 2025 21:43:26 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Thanks to make it so clear, I did similar evaluation and knew we will call arraycopy_work when (B && C) is true, but it shouldn't cause crash from OldGC, we will be more conservative in such case resulting in maybe more live objects.
>> 
>> I'll try to make the tests here more accurate in the PR.
>
> arraycopy_work will be called when (B && C) is true if only A is also true, it is expected and what we wanted.

Condition `D` should be sufficient when we are marking old. That is, I don't believe we need to check `B` or `C` when we are marking old.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600245936

From xpeng at openjdk.org  Mon Dec  8 21:51:00 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 21:51:00 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <iO5qOvEAvEmYjkRf2h0ixQZ9QGe318CMwpD_EPapyFY=.2289094f-2a91-45ae-826b-6bafd6399be5@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
 <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
 <ZfbROnRYXCf9kH1T5mO2i2luwBnkW4FMZaFRHOhT7to=.647cb5f0-e79b-4445-a0b6-e4f474c55b5f@github.com>
 <4V8h9n8guTinNiCNYtecwcEKZb4y8zz6Qnwidpc4lC4=.149b8dd2-e5d5-45ad-9f93-12be677a2072@github.com>
 <hD4jJ0NaAgU0XNe_UrRzT21CC-F6ctXmDA-t74JXG2o=.3f587de4-8446-436a-8aac-a6148723ed82@github.com>
 <iO5qOvEAvEmYjkRf2h0ixQZ9QGe318CMwpD_EPapyFY=.2289094f-2a91-45ae-826b-6bafd6399be5@github.com>
Message-ID: <LKKva_raQVxxJPvGgBdJiTvcqK921wq5vNX6xjOU9i8=.ee55512f-91b9-4048-ac76-e18269c2d537@github.com>

On Mon, 8 Dec 2025 21:44:24 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> arraycopy_work will be called when (B && C) is true if only A is also true, it is expected and what we wanted.
>
> Condition `D` should be sufficient when we are marking old. That is, I don't believe we need to check `B` or `C` when we are marking old.

There is one case, I think we may not want to make the test here overly complicated so I didn't add it:
(!A && B && C && !D) 

It could after final-mark in bootstrap young GC, the young marking has done, old marking is in progress.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600258109

From xpeng at openjdk.org  Mon Dec  8 22:38:13 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 22:38:13 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v8]
In-Reply-To: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
Message-ID: <3Z0T1qrYELdfc_aZ-nN64JnCUG4pKB6I5TKZa_aAeKQ=.464424cb-b086-45b6-86d7-2116db07e06b@github.com>

> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
> 
> It is caused by the behavior change from follow code:
> 
> Original:
> 
>   if (ShenandoahSATBBarrier) {
>     T* array = dst;
>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>     if (is_old_marking) {
>       // Generational, old marking
>       assert(_heap->mode()->is_generational(), "Invariant");
>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (_heap->mode()->is_generational()) {
>       // Generational, young marking
>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>       // Non-generational, marking
>       arraycopy_work<T, false, false, true>(array, count);
>     }
>   }
> 
> New:
> 
>   if (ShenandoahSATBBarrier) {
>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>       arraycopy_work<T, false, false, true>(dst, count);
>     }
>   }
> 
> 
> 
> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
> - [x] GHA

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

 - Remove header
 - Remove card assert, pass IS_GENERATIONAL as template parameter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28669/files
  - new: https://git.openjdk.org/jdk/pull/28669/files/225b999d..fe272ab8

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

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

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

From xpeng at openjdk.org  Mon Dec  8 22:38:15 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 22:38:15 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <LKKva_raQVxxJPvGgBdJiTvcqK921wq5vNX6xjOU9i8=.ee55512f-91b9-4048-ac76-e18269c2d537@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
 <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
 <ZfbROnRYXCf9kH1T5mO2i2luwBnkW4FMZaFRHOhT7to=.647cb5f0-e79b-4445-a0b6-e4f474c55b5f@github.com>
 <4V8h9n8guTinNiCNYtecwcEKZb4y8zz6Qnwidpc4lC4=.149b8dd2-e5d5-45ad-9f93-12be677a2072@github.com>
 <hD4jJ0NaAgU0XNe_UrRzT21CC-F6ctXmDA-t74JXG2o=.3f587de4-8446-436a-8aac-a6148723ed82@github.com>
 <iO5qOvEAvEmYjkRf2h0ixQZ9QGe318CMwpD_EPapyFY=.2289094f-2a91-45ae-826b-6bafd6399be5@github.com>
 <LKKva_raQVxxJPvGgBdJiTvcqK921wq5vNX6xjOU9i8=.ee55512f-91b9-4048-ac76-e18269c2d537@github.com>
Message-ID: <H8RIHKAQ0bZva0PfZTNGEMi7TyWEyM0demDwbfuh0cU=.2b3a011e-2879-4995-af01-0abc5a8c7533@github.com>

On Mon, 8 Dec 2025 21:48:10 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Condition `D` should be sufficient when we are marking old. That is, I don't believe we need to check `B` or `C` when we are marking old.
>
> There is one case, I think we may not want to make the test here overly complicated so I didn't add it:
> (!A && B && C && !D) 
> 
> It could happen after final-mark in bootstrap young GC, the young marking has done, old marking is in progress.

I have updated PR, now is_generational is passed to the method as template parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600363483

From xpeng at openjdk.org  Mon Dec  8 22:38:16 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 22:38:16 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <KyPIVrhUKUc7t9Bmhe1J6EDal6uGDXnsbXWj4ixX9xQ=.fa6c790e-6224-4192-a973-047a85cd9dd2@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
 <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
 <KyPIVrhUKUc7t9Bmhe1J6EDal6uGDXnsbXWj4ixX9xQ=.fa6c790e-6224-4192-a973-047a85cd9dd2@github.com>
Message-ID: <F3B5Z9-AVobCBFHwXwcSNg16hX2DAeCl3BhDqWjbgaE=.38a6d60a-b0b7-44a1-8549-ca11074bd471@github.com>

On Mon, 8 Dec 2025 21:25:46 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 464:
>> 
>>> 462:             assert(!_heap->is_in_young(obj) ||
>>> 463:                    card_scan->is_card_dirty(elem_heap_word_ptr) ||
>>> 464:                    card_scan->is_write_card_dirty(elem_heap_word_ptr),
>> 
>> I believe there is a very slight risk of assertion failure here, which might be so rare that you could just mention the possibility in the "error message" or in a comment associated with this code.
>> 
>> The race is that some other thread could overwrite an an old-gen array element with pointer to young during young marking, and we might see this interesting young pointer before that other thread has had a chance to mark the associated card dirty.
>
> Yes, it is still possible to fail because during arraycopy, there could be mutators updating objects in the array or doing arraycopy, they will update the write card at the same time. 
> 
> With the better understanding of ShenandoahSATBBarrier and ShenandoahCardBarrier after the discussions, I don't think it make sense to add the these asserts. We are verifying the behavior of ShenandoahCardBarrier in the ShenandoahSATBBarrier code, which is weird and will confuse people when will read the code in the further.

I have removed the asserts, given that it is not possible the guarantee that the assert will always pass, also I think we shall not verify the behavior of ShenandoahCardBarrier in the ShenandoahSATBBarrier code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600367406

From xpeng at openjdk.org  Mon Dec  8 22:47:45 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 8 Dec 2025 22:47:45 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v9]
In-Reply-To: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
Message-ID: <4xcQSCGc6pweN2V4QQqX02_e06yCoXEEDPC5fH50DUE=.b2e0d913-af28-4b38-9bb4-652fbbdab614@github.com>

> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
> 
> It is caused by the behavior change from follow code:
> 
> Original:
> 
>   if (ShenandoahSATBBarrier) {
>     T* array = dst;
>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>     if (is_old_marking) {
>       // Generational, old marking
>       assert(_heap->mode()->is_generational(), "Invariant");
>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (_heap->mode()->is_generational()) {
>       // Generational, young marking
>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>       // Non-generational, marking
>       arraycopy_work<T, false, false, true>(array, count);
>     }
>   }
> 
> New:
> 
>   if (ShenandoahSATBBarrier) {
>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>       arraycopy_work<T, false, false, true>(dst, count);
>     }
>   }
> 
> 
> 
> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
> - [x] GHA

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Fix indent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28669/files
  - new: https://git.openjdk.org/jdk/pull/28669/files/fe272ab8..9e186a85

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

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

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

From wkemper at openjdk.org  Mon Dec  8 22:59:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Dec 2025 22:59:56 GMT
Subject: RFR: 8373272: Genshen: ShenandoahOldGenerationTest fails after
 JDK-8373056
In-Reply-To: <eBbU9Nhz4n_44kDdQFTcB-_bUI9v03dEFO8lMPBW0t8=.6b45e880-2e8b-40ff-bafc-71c4997f87ae@github.com>
References: <eBbU9Nhz4n_44kDdQFTcB-_bUI9v03dEFO8lMPBW0t8=.6b45e880-2e8b-40ff-bafc-71c4997f87ae@github.com>
Message-ID: <r5sNgVHyrAYOGgLDmHorPMG_dALkq0GSVoJWaxxsa6Y=.20138cc5-160a-4c82-94fe-db1f43460345@github.com>

On Mon, 8 Dec 2025 19:32:16 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> ShenandoahOldGeneration::configure_plab_for_current_thread has been updated to only handle plab req, which is a behavior change, but ShenandoahOldGenerationTest was not updated to match the behavior change, causing the test to fail.
> 
> The two failing unit tests of ShenandoahOldGenerationTest have been removed in this PR since the behavior being verified with them is no longer in configure_plab_for_current_thread, meanwhile one more unit test is added to verify the behavior of `expend_promoted`
> 
> ### Test
> - [x] CONF=macosx-aarch64-server-fastdebug make test TEST=gtest
> - [x] CONF=macosx-aarch64-server-fastdebug make test TEST=hotspot_gc_shenandoah

Thank you!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28706#pullrequestreview-3554431253

From wkemper at openjdk.org  Mon Dec  8 23:01:57 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Dec 2025 23:01:57 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v9]
In-Reply-To: <4xcQSCGc6pweN2V4QQqX02_e06yCoXEEDPC5fH50DUE=.b2e0d913-af28-4b38-9bb4-652fbbdab614@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <4xcQSCGc6pweN2V4QQqX02_e06yCoXEEDPC5fH50DUE=.b2e0d913-af28-4b38-9bb4-652fbbdab614@github.com>
Message-ID: <V8qspgcdZ3E2xebzGAzq769KNAr93Do1zh9wfT7WKVo=.5b506e9a-ca37-4672-afa8-3e1e56dd0807@github.com>

On Mon, 8 Dec 2025 22:47:45 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28669#pullrequestreview-3554437116

From btaylor at openjdk.org  Mon Dec  8 23:29:58 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Mon, 8 Dec 2025 23:29:58 GMT
Subject: RFR: 8352914: Shenandoah: Change definition of
 ShenandoahSharedValue to int32_t to leverage platform atomics
In-Reply-To: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
References: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
Message-ID: <SmMP18FIB6pb_jPuKMCk65utVbJV0Ozeyojdeto_vmc=.e1e161cd-c4a8-413a-a061-2f57f4271637@github.com>

On Fri, 5 Dec 2025 18:44:08 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The `STATIC_ASSERT` below this typedef appears to be out of date. 
> 
> The barriers check thread local copy of gc state, which is stored in `ShenandoahThreadLocalData::_gc_state`  and is type `char`, so the size requirement described by the assert is maintained even after this change.
> 
> Change passes all tier1 tests locally when run with Shenandoah GC.

I will check some performance numbers before and after this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/28681#issuecomment-3629462825

From duke at openjdk.org  Mon Dec  8 23:29:59 2025
From: duke at openjdk.org (duke)
Date: Mon, 8 Dec 2025 23:29:59 GMT
Subject: RFR: 8352914: Shenandoah: Change definition of
 ShenandoahSharedValue to int32_t to leverage platform atomics
In-Reply-To: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
References: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
Message-ID: <6LAY0z9qrgg4ejX6fH_yO1s2eXRTxdQpffa7-mrER84=.f35776d1-6b7a-4863-977c-f59825c12f0a@github.com>

On Fri, 5 Dec 2025 18:44:08 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The `STATIC_ASSERT` below this typedef appears to be out of date. 
> 
> The barriers check thread local copy of gc state, which is stored in `ShenandoahThreadLocalData::_gc_state`  and is type `char`, so the size requirement described by the assert is maintained even after this change.
> 
> Change passes all tier1 tests locally when run with Shenandoah GC.

@benty-amzn 
Your change (at version 90923ab3b090ae4021bcb4bf47076f6124cd2491) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28681#issuecomment-3629465464

From duke at openjdk.org  Tue Dec  9 00:03:58 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 9 Dec 2025 00:03:58 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect [v3]
In-Reply-To: <nDhDGPSvzovYIsAP0jKr311TFj72ZzxR72UkkcofcVk=.cfd87dcc-1f74-4445-9be9-4f3ae1fbc478@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
 <nDhDGPSvzovYIsAP0jKr311TFj72ZzxR72UkkcofcVk=.cfd87dcc-1f74-4445-9be9-4f3ae1fbc478@github.com>
Message-ID: <fKpxucMNNRS3xZDglMoFQ4Xh2kmkeVqUgwaibowVr_I=.5325cf2b-3c40-4268-8a8e-57b7acb8dc4f@github.com>

On Thu, 4 Dec 2025 02:19:32 GMT, Rui Li <duke at openjdk.org> wrote:

>> Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 
>> 
>> Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:
>> 
>> 
>> available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
>> soft_tail = Xmx - soft_max
>> if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 
>> 
>> 
>> The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.
>> 
>> 
>> Suggested fix: when deciding when to trigger gc, use logic similar to below:
>> 
>> mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
>> available = mutator_soft_capacity - used;
>> if (available < mutator_soft_capacity) // trigger gc
>> ``` 
>> 
>> Tests:
>> - Ran the repro app `StableLiveSet.java` in https://bugs.openjdk.org/browse/JDK-8372543. Without fix, tip had ~2910 times gc in 20 sec with `-XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=adaptive -XX:SoftMaxHeapSize=512m -Xmx31g` jvm args. With the fix, only 18 times in 20 sec.
>> - GHA passed.
>> 
>> -------
>> This change also improved gc logging:
>> 
>> Before:
>> 
>> [6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
>> [6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
>> external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B
>> 
>> 
>> After:
>> 
>> [8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
>> [8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
>> 1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
>> 1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
>> 122, Reserved: 102M, Max free available in a single region: 1024K;
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused freeset includes

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 255:

> 253:   size_t min_threshold = min_free_threshold();
> 254:   if (available < min_threshold) {
> 255:     log_trigger("Free (Soft) (%zu%s) is below minimum threshold (%zu%s)",

Forgot to use log format macros `PROPERFMT` & `PROPERFMTARGS` here. Will update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2600564531

From kdnilsen at openjdk.org  Tue Dec  9 00:06:56 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 00:06:56 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics
In-Reply-To: <g50NQReQ49atVxRT_voQYiyH2fnZIlbhavT_dGOvgRo=.3e69b820-ec94-4319-a4ee-d03c6fff4c41@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <g50NQReQ49atVxRT_voQYiyH2fnZIlbhavT_dGOvgRo=.3e69b820-ec94-4319-a4ee-d03c6fff4c41@github.com>
Message-ID: <TX8Sx92dOOPVDwhQY7uEGfCwu0in3dGuRr2L3l5lggE=.70bfa134-60d0-460a-ad4a-666f5e949d13@github.com>

On Mon, 8 Dec 2025 16:41:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
>> 
>> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 252:
> 
>> 250:     (_live_bytes_after_last_mark + ((ShenandoahHeap::heap()->soft_max_capacity() - _live_bytes_after_last_mark)
>> 251:                                     * ShenandoahMinOldGenGrowthRemainingHeapPercent / 100.0));
>> 252:   size_t result = MIN2(threshold_by_relative_growth, threshold_by_growth_into_percent_remaining);
> 
> Are we comparing bytes to a percentage here? Not sure I understand the role of `FRACTIONAL_DENOMINATOR`.

I'll take this opportunity to simplify that code.  We're using a percent.  Next version of code should be more clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2600571373

From btaylor at openjdk.org  Tue Dec  9 00:20:20 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Tue, 9 Dec 2025 00:20:20 GMT
Subject: Integrated: 8352914: Shenandoah: Change definition of
 ShenandoahSharedValue to int32_t to leverage platform atomics
In-Reply-To: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
References: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
Message-ID: <xjYyoqaFFH4G6p6zCi5M01cYtSwR7BBKpdmfGd9lwQs=.e3163ff0-556f-4b38-9f4b-4ba80f39ea9a@github.com>

On Fri, 5 Dec 2025 18:44:08 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The `STATIC_ASSERT` below this typedef appears to be out of date. 
> 
> The barriers check thread local copy of gc state, which is stored in `ShenandoahThreadLocalData::_gc_state`  and is type `char`, so the size requirement described by the assert is maintained even after this change.
> 
> Change passes all tier1 tests locally when run with Shenandoah GC.

This pull request has now been integrated.

Changeset: b86b2cbc
Author:    Ben Taylor <btaylor at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b86b2cbc7d9dd57aeaf64f70f248a120ae3cb751
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8352914: Shenandoah: Change definition of ShenandoahSharedValue to int32_t to leverage platform atomics

Reviewed-by: wkemper, ysr

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

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

From xpeng at openjdk.org  Tue Dec  9 01:20:08 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 9 Dec 2025 01:20:08 GMT
Subject: RFR: 8373272: Genshen: ShenandoahOldGenerationTest fails after
 JDK-8373056
In-Reply-To: <r5sNgVHyrAYOGgLDmHorPMG_dALkq0GSVoJWaxxsa6Y=.20138cc5-160a-4c82-94fe-db1f43460345@github.com>
References: <eBbU9Nhz4n_44kDdQFTcB-_bUI9v03dEFO8lMPBW0t8=.6b45e880-2e8b-40ff-bafc-71c4997f87ae@github.com>
 <r5sNgVHyrAYOGgLDmHorPMG_dALkq0GSVoJWaxxsa6Y=.20138cc5-160a-4c82-94fe-db1f43460345@github.com>
Message-ID: <-h78N1QQaMBV1JcYat9SZfxw0zsA4mC_0RQrLWlK2ic=.3e3eaf57-deea-4561-922d-0856418a2730@github.com>

On Mon, 8 Dec 2025 22:57:33 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> ShenandoahOldGeneration::configure_plab_for_current_thread has been updated to only handle plab req, which is a behavior change, but ShenandoahOldGenerationTest was not updated to match the behavior change, causing the test to fail.
>> 
>> The two failing unit tests of ShenandoahOldGenerationTest have been removed in this PR since the behavior being verified with them is no longer in configure_plab_for_current_thread, meanwhile one more unit test is added to verify the behavior of `expend_promoted`
>> 
>> ### Test
>> - [x] CONF=macosx-aarch64-server-fastdebug make test TEST=gtest
>> - [x] CONF=macosx-aarch64-server-fastdebug make test TEST=hotspot_gc_shenandoah
>
> Thank you!

Thank you @earthling-amzn! 
I'll integrate it now considering that these testes are blocking our CI workflows.

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

PR Comment: https://git.openjdk.org/jdk/pull/28706#issuecomment-3629760071

From xpeng at openjdk.org  Tue Dec  9 01:20:09 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 9 Dec 2025 01:20:09 GMT
Subject: Integrated: 8373272: Genshen: ShenandoahOldGenerationTest fails after
 JDK-8373056
In-Reply-To: <eBbU9Nhz4n_44kDdQFTcB-_bUI9v03dEFO8lMPBW0t8=.6b45e880-2e8b-40ff-bafc-71c4997f87ae@github.com>
References: <eBbU9Nhz4n_44kDdQFTcB-_bUI9v03dEFO8lMPBW0t8=.6b45e880-2e8b-40ff-bafc-71c4997f87ae@github.com>
Message-ID: <pMG3SmiKTTa-rgXVQ9DEL_BZzxDJVnpBjD11h-yvZEg=.23d81bd3-54e2-46fc-a215-0fc781ace63f@github.com>

On Mon, 8 Dec 2025 19:32:16 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> ShenandoahOldGeneration::configure_plab_for_current_thread has been updated to only handle plab req, which is a behavior change, but ShenandoahOldGenerationTest was not updated to match the behavior change, causing the test to fail.
> 
> The two failing unit tests of ShenandoahOldGenerationTest have been removed in this PR since the behavior being verified with them is no longer in configure_plab_for_current_thread, meanwhile one more unit test is added to verify the behavior of `expend_promoted`
> 
> ### Test
> - [x] CONF=macosx-aarch64-server-fastdebug make test TEST=gtest
> - [x] CONF=macosx-aarch64-server-fastdebug make test TEST=hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 3ea82b9f
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ea82b9ff90aebc1a169fdd967c44408dc4a4f51
Stats:     26 lines in 1 file changed: 0 ins; 23 del; 3 mod

8373272: Genshen: ShenandoahOldGenerationTest fails after JDK-8373056

Reviewed-by: wkemper

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

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

From kdnilsen at openjdk.org  Tue Dec  9 01:23:30 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 01:23:30 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v2]
In-Reply-To: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
Message-ID: <7UZLMmJ563BYtqd7cxmV3NIMc9LhzQFym6qLGBkXqFc=.ee43602e-8a4c-4bb3-acc4-267ee0a909ec@github.com>

> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
> 
> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.

Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:

 - Add comment to describe behavior of adjust_old_garbage_threshold()
 - Simplify representation of growth percentages
 - Change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28561/files
  - new: https://git.openjdk.org/jdk/pull/28561/files/3c9a86ee..d5e4072d

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

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

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

From kdnilsen at openjdk.org  Tue Dec  9 01:23:31 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 01:23:31 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v2]
In-Reply-To: <g50NQReQ49atVxRT_voQYiyH2fnZIlbhavT_dGOvgRo=.3e69b820-ec94-4319-a4ee-d03c6fff4c41@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <g50NQReQ49atVxRT_voQYiyH2fnZIlbhavT_dGOvgRo=.3e69b820-ec94-4319-a4ee-d03c6fff4c41@github.com>
Message-ID: <FEUZq8dTVh9S3tsLRzf3E726xKw8kwc4dpJapm4dyVY=.77b288e7-717e-40c7-bcab-7b7b8a93f81a@github.com>

On Mon, 8 Dec 2025 16:32:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Add comment to describe behavior of adjust_old_garbage_threshold()
>>  - Simplify representation of growth percentages
>>  - Change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 212:
> 
>> 210:   void slide_pinned_regions_to_front();
>> 211:   bool all_candidates_are_pinned();
>> 212:   void adjust_old_garbage_threshold();
> 
> A brief general comment about the algorithm here or in the implementation would be welcome. As I read it, we are lowering the region's garbage threshold as the occupancy in the old generation increases. Lowering the garbage threshold will increase the number of old regions selected for a mixed collection.

Thanks.  I've added this description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2600711259

From kdnilsen at openjdk.org  Tue Dec  9 01:27:03 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 01:27:03 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v7]
In-Reply-To: <H8RIHKAQ0bZva0PfZTNGEMi7TyWEyM0demDwbfuh0cU=.2b3a011e-2879-4995-af01-0abc5a8c7533@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <PEyG1UAjnlt0ilBiykoaXBYq8lzmJSwNqk4nqOdpVAw=.9fc60ef0-4bcb-4e40-9ba3-0118f4ace702@github.com>
 <lVGc72Ywa58EXQDQDVDoe_J3-V4PeQk2AvLw4pEjWhw=.518bdc7b-6af2-4ce9-b84c-45b990a2a26f@github.com>
 <ZfbROnRYXCf9kH1T5mO2i2luwBnkW4FMZaFRHOhT7to=.647cb5f0-e79b-4445-a0b6-e4f474c55b5f@github.com>
 <4V8h9n8guTinNiCNYtecwcEKZb4y8zz6Qnwidpc4lC4=.149b8dd2-e5d5-45ad-9f93-12be677a2072@github.com>
 <hD4jJ0NaAgU0XNe_UrRzT21CC-F6ctXmDA-t74JXG2o=.3f587de4-8446-436a-8aac-a6148723ed82@github.com>
 <iO5qOvEAvEmYjkRf2h0ixQZ9QGe318CMwpD_EPapyFY=.2289094f-2a91-45ae-826b-6bafd6399be5@github.com>
 <LKKva_raQVxxJPvGgBdJiTvcqK921wq5vNX6xjOU9i8=.ee55512f-91b9-4048-ac76-e18269c2d537@github.com>
 <H8RIHKAQ0bZva0PfZTNGEMi7TyWEyM0demDwbfuh0cU=.2b3a011e-2879-4995-af01-0abc5a8c7533@github.com>
Message-ID: <n8_2616jv7ixQqXv3a8k4M7WAVRlJxPI7-tQnnskOCo=.4c815557-4080-4a18-873f-6c711fecb663@github.com>

On Mon, 8 Dec 2025 22:32:49 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> There is one case, I think we may not want to make the test here overly complicated so I didn't add it:
>> (!A && B && C && !D) 
>> 
>> It could happen after final-mark in bootstrap young GC, the young marking has done, old marking is in progress.
>
> I have updated PR, now is_generational is passed to the method as template parameter.

When marking OLD and not marking YOUNG, there is no need to enforce SATB on array_copy if the destination resides in young.  That is because such an array would essentially reside above the old-generation marking TAMS.

I understand that we may choose to be a bit less aggressive in how much we optimize for improved code clarity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28669#discussion_r2600717666

From kdnilsen at openjdk.org  Tue Dec  9 01:29:57 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 01:29:57 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v9]
In-Reply-To: <4xcQSCGc6pweN2V4QQqX02_e06yCoXEEDPC5fH50DUE=.b2e0d913-af28-4b38-9bb4-652fbbdab614@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <4xcQSCGc6pweN2V4QQqX02_e06yCoXEEDPC5fH50DUE=.b2e0d913-af28-4b38-9bb4-652fbbdab614@github.com>
Message-ID: <HUSD_fpr-7yf7gevQwPH6XQheR33IdweqeSYhtt-ztI=.943d77d6-01c7-48c0-bc2a-96b1d4d899e3@github.com>

On Mon, 8 Dec 2025 22:47:45 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28669#pullrequestreview-3554842845

From kdnilsen at openjdk.org  Tue Dec  9 03:12:37 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 03:12:37 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v3]
In-Reply-To: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
Message-ID: <9gzZlrEzwroH2F-yEC6uzYIPsoKEcTBs_6UZDNFvvCg=.e0e0697f-e537-41fb-9f7f-740acbab4ad1@github.com>

> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
> 
> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.

Kelvin Nilsen 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 12 additional commits since the last revision:

 - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers-gh
 - Add comment to describe behavior of adjust_old_garbage_threshold()
 - Simplify representation of growth percentages
 - Change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
 - make old evac ratio adaptive
 - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
 - change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
 - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
 - Adjust test for new defaults
 - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
 - ... and 2 more: https://git.openjdk.org/jdk/compare/edebc413...c7c22974

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28561/files
  - new: https://git.openjdk.org/jdk/pull/28561/files/d5e4072d..c7c22974

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

  Stats: 12179 lines in 61 files changed: 8415 ins; 3463 del; 301 mod
  Patch: https://git.openjdk.org/jdk/pull/28561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28561/head:pull/28561

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

From xpeng at openjdk.org  Tue Dec  9 03:31:09 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 9 Dec 2025 03:31:09 GMT
Subject: RFR: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking [v9]
In-Reply-To: <4xcQSCGc6pweN2V4QQqX02_e06yCoXEEDPC5fH50DUE=.b2e0d913-af28-4b38-9bb4-652fbbdab614@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
 <4xcQSCGc6pweN2V4QQqX02_e06yCoXEEDPC5fH50DUE=.b2e0d913-af28-4b38-9bb4-652fbbdab614@github.com>
Message-ID: <g3bX1hOR-WXD2vqfic-vGw0NRRp2HuAHqIO4wW8baqg=.156db3de-78cb-4fd6-af68-ef208efa8491@github.com>

On Mon, 8 Dec 2025 22:47:45 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
>> 
>> It is caused by the behavior change from follow code:
>> 
>> Original:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     T* array = dst;
>>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>>     if (is_old_marking) {
>>       // Generational, old marking
>>       assert(_heap->mode()->is_generational(), "Invariant");
>>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (_heap->mode()->is_generational()) {
>>       // Generational, young marking
>>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>>         arraycopy_work<T, false, false, true>(array, count);
>>       }
>>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>>       // Non-generational, marking
>>       arraycopy_work<T, false, false, true>(array, count);
>>     }
>>   }
>> 
>> New:
>> 
>>   if (ShenandoahSATBBarrier) {
>>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>>       arraycopy_work<T, false, false, true>(dst, count);
>>     }
>>   }
>> 
>> 
>> 
>> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Thank you all for the reviews and valuable feedbacks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28669#issuecomment-3630074748

From xpeng at openjdk.org  Tue Dec  9 03:31:10 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 9 Dec 2025 03:31:10 GMT
Subject: Integrated: 8373116: Genshen: arraycopy_work should be always done for
 arrays in old gen during young concurrent marking
In-Reply-To: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
References: <R92GmsT_w4mHYGRK5ih3UMvJGFDADLwFgbiQ5-URMfY=.552a7e02-61b3-41f9-aa43-ba2eca8e3f64@github.com>
Message-ID: <ilHVHbC0SpvW3nCAxoLHcKQGu17XGwYuLukGLcyP2Ac=.fb7b4dcb-5c73-427a-bb60-79c0f60a9299@github.com>

On Thu, 4 Dec 2025 22:14:50 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Chasing the root cause of JDK-8372498, I have narrowed down root cause to the commit https://github.com/openjdk/jdk/commit/f8cf9ca69cfef286c80559bfe1d147b6303d10d2
> 
> It is caused by the behavior change from follow code:
> 
> Original:
> 
>   if (ShenandoahSATBBarrier) {
>     T* array = dst;
>     HeapWord* array_addr = reinterpret_cast<HeapWord*>(array);
>     ShenandoahHeapRegion* r = _heap->heap_region_containing(array_addr);
>     if (is_old_marking) {
>       // Generational, old marking
>       assert(_heap->mode()->is_generational(), "Invariant");
>       if (r->is_old() && (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (_heap->mode()->is_generational()) {
>       // Generational, young marking
>       if (r->is_old() || (array_addr < _heap->marking_context()->top_at_mark_start(r))) {
>         arraycopy_work<T, false, false, true>(array, count);
>       }
>     } else if (array_addr < _heap->marking_context()->top_at_mark_start(r)) {
>       // Non-generational, marking
>       arraycopy_work<T, false, false, true>(array, count);
>     }
>   }
> 
> New:
> 
>   if (ShenandoahSATBBarrier) {
>     if (!_heap->marking_context()->allocated_after_mark_start(reinterpret_cast<HeapWord*>(dst))) {
>       arraycopy_work<T, false, false, true>(dst, count);
>     }
>   }
> 
> 
> 
> With the new STAB barrier code for arraycopy_marking, if is it young GC and the array is in old region, but array is above TAMS(Old GC may not be started, TAMS of old region is not captured), arraycopy_work won't be applied anymore, so we may have missed some pointers in SATB in such case during concurrent young marking. 
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] repeat gc/TestAllocHumongousFragment.java#generational and sure it won't crash with the fix
> - [x] GHA

This pull request has now been integrated.

Changeset: c9ab330b
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3
Stats:     10 lines in 2 files changed: 5 ins; 0 del; 5 mod

8373116: Genshen: arraycopy_work should be always done for arrays in old gen during young concurrent marking
8372498: [genshen] gc/TestAllocHumongousFragment.java#generational causes intermittent SIGSEGV crashes

Reviewed-by: wkemper, kdnilsen

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

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

From xpeng at openjdk.org  Tue Dec  9 07:45:26 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 9 Dec 2025 07:45:26 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v16]
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <pdIph8lihWZPyzmvTvxA5snwNXB9KYo8eG_76y6YWuA=.19c27661-cba2-417f-a5ba-0e6e272ea76a@github.com>

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code:
> 
> * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class.
> * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and  `_yield_to_safepoint` to customize the allocator for mutator.
> * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. 
> * ShenandoahOldCollectorAllocator:  allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector`
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. 
> 
> java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> 
> 
> Openjdk TIP:
> 
> ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 2...

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 260 commits:

 - Fix build failure after merge
 - Expend promoted from ShenandoahOldCollectorAllocator
 - Merge branch 'master' into cas-alloc-1
 - Address PR comments
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Add missing header for ShenandoahFreeSetPartitionId
 - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
 - Fix a typo
 - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
 - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
 - ... and 250 more: https://git.openjdk.org/jdk/compare/5f083aba...06366b4b

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

Changes: https://git.openjdk.org/jdk/pull/26171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=15
  Stats: 1642 lines in 25 files changed: 1295 ins; 235 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

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

From ayang at openjdk.org  Tue Dec  9 09:17:51 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 9 Dec 2025 09:17:51 GMT
Subject: RFR: 8373335: Serial: Clean up SerialHeap members by access specifies
Message-ID: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>

Trivial moving member of `SerialHeap` so that all `private` fields/methods are altogether (at the top).
 
Test: tier1

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

Commit messages:
 - sgc-private

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

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

From rsunderbabu at openjdk.org  Tue Dec  9 09:18:13 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 9 Dec 2025 09:18:13 GMT
Subject: Integrated: 8319326: GC: Make TestParallelRefProc use
 createTestJavaProcessBuilder
In-Reply-To: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
References: <b-isPwiZyPOwI0JRPsDXUdK35CXWd4eYoYxNR-1Ruws=.8aeae6ee-a008-4960-b119-9762a257f020@github.com>
Message-ID: <Ox1gfXmGmjgPaggpTkxRCpoLJ_lCSJ1vYlTCQcQ6r54=.c0c15533-d0ce-4622-9cc9-e8341c7a0842@github.com>

On Wed, 26 Nov 2025 14:35:20 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Summary of change:
> 
> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
> 2. Allowing GC flags will result in VM initialization error ("Multiple garbage collectors selected"). So, test is split into separate sections pertaining to GC requirements. @requires now has corresponding GC flag condition.
> 3. Removal of WhiteBox dependency and few cleanups.
> 
> Testing:
> HS Tiers 1 and 2 
> Ran with all flag combinations in CI

This pull request has now been integrated.

Changeset: 3a8a6e07
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a8a6e07f2a2cffa467815df55e746e92765903d
Stats:     62 lines in 1 file changed: 34 ins; 5 del; 23 mod

8319326: GC: Make TestParallelRefProc use createTestJavaProcessBuilder

Reviewed-by: stefank, iwalulya

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

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

From rsunderbabu at openjdk.org  Tue Dec  9 09:20:24 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 9 Dec 2025 09:20:24 GMT
Subject: Integrated: 8319161: GC: Make TestParallelGCThreads use
 createTestJavaProcessBuilder
In-Reply-To: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
References: <nc2X2KuN-IZ_62HF4tgZFjRJFH_8dAkugO9FBQZ-BrY=.d05b7774-b754-423a-9172-ae4306735177@github.com>
Message-ID: <gDnSU7-WLrojgMOTZfgw09mNJZKETW9XwevKbTvDJq8=.e304a3db-f588-45ea-8f93-eece24c8bee2@github.com>

On Sat, 29 Nov 2025 12:40:39 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Summary of change:
> 
> 1. executeLimitedTestJava changed to executeTestJava to allow flags to be propagated to forked processes.
> 2. Test is split into separate sections pertaining to GC requirements. @requires now has corresponding GC flag condition.
> 3. Addition of ZGC to list of parallel collectors
> 
> Testing:
> HS Tiers 1 and 2
> Ran with all flag combinations in CI

This pull request has now been integrated.

Changeset: 24244e41
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/24244e41210be5b71b9e8238badbf975ed4b02ef
Stats:     114 lines in 1 file changed: 66 ins; 23 del; 25 mod

8319161: GC: Make TestParallelGCThreads use createTestJavaProcessBuilder

Reviewed-by: stefank, iwalulya

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

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

From jsikstro at openjdk.org  Tue Dec  9 09:35:56 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 9 Dec 2025 09:35:56 GMT
Subject: RFR: 8373335: Serial: Clean up SerialHeap members by access
 specifies
In-Reply-To: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>
References: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>
Message-ID: <BTxeQWZwOIs3LmnqaD50xr5ZkN5F1kj-Wioa8bEKUAs=.5948906d-7352-4ba5-8b55-f9e6b74fdd6c@github.com>

On Tue, 9 Dec 2025 09:08:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial moving member of `SerialHeap` so that all `private` fields/methods are altogether (at the top).
>  
> Test: tier1

Changes look good. Some comments while looking at this:

`save_marks` was public and is now private, which is fine since it is only called internally.

These two member variables are not initialized in the constructor like all other member variables:

HeapWord* _young_gen_saved_top;
HeapWord* _old_gen_saved_top;


The implementation order for most methods in serialHeap.cpp is quite different from the declaration/definition order in serialHeap.hpp, which is something we might also want to fix.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28718#pullrequestreview-3556359446

From aboldtch at openjdk.org  Tue Dec  9 10:07:35 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 9 Dec 2025 10:07:35 GMT
Subject: RFR: 8373025: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may
 deadlock [v3]
In-Reply-To: <9zSX9cB_iSIS1DcYhh4X0fQMg_0LxhzrFpEdVh73tPA=.b29ee8ec-3cbf-496c-a6d9-4d56831c75f1@github.com>
References: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
 <9zSX9cB_iSIS1DcYhh4X0fQMg_0LxhzrFpEdVh73tPA=.b29ee8ec-3cbf-496c-a6d9-4d56831c75f1@github.com>
Message-ID: <JCNay6mLXiQyB7grGH5y3SnjCxDEbPK2qk8To5EXrV4=.d1c00256-d126-46fa-a286-b16b0d1757a8@github.com>

On Wed, 3 Dec 2025 18:37:44 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
>> 
>> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
>> 
>> * Testing
>>   * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
>>   * GHA
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Remove problem-listing
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8373025
>  - Need to support windows as well
>  - Remove unused variable
>  - Fix the comment
>  - 8373025: Test: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28638#issuecomment-3631367060

From aboldtch at openjdk.org  Tue Dec  9 10:07:37 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 9 Dec 2025 10:07:37 GMT
Subject: Integrated: 8373025: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java
 may deadlock
In-Reply-To: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
References: <V8kEJhbS8RJG5N16XzTX8-ngzBHLlzWSACDLlHoGGHk=.c3714744-f926-4a15-8cf0-053c5b3c6020@github.com>
Message-ID: <eEvD9topp2grDzPDPDlZL66CbbKgIYXsz4vI20SVIbw=.8f7c1224-f38b-4b3b-b86d-0510f2ddf93f@github.com>

On Wed, 3 Dec 2025 15:10:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
> 
> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
> 
> * Testing
>   * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
>   * GHA

This pull request has now been integrated.

Changeset: 0a557890
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a557890a50b0dc83c70dc877027d951dcc05470
Stats:     45 lines in 3 files changed: 14 ins; 25 del; 6 mod

8373025: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock

Reviewed-by: ayang, tschatzl, stefank

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

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

From ayang at openjdk.org  Tue Dec  9 10:28:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 9 Dec 2025 10:28:05 GMT
Subject: RFR: 8373335: Serial: Clean up SerialHeap members by access
 specifies [v2]
In-Reply-To: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>
References: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>
Message-ID: <DD9aV2kL8autSQHgUH1Mf2ndxvmsErJmWxr0gUgjJT4=.0fce4b73-b92d-486c-97b8-6b4d63d4fe41@github.com>

> Trivial moving member of `SerialHeap` so that all `private` fields/methods are altogether (at the top).
>  
> Test: tier1

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28718/files
  - new: https://git.openjdk.org/jdk/pull/28718/files/d3d84874..e12f7409

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

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

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

From ayang at openjdk.org  Tue Dec  9 10:32:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 9 Dec 2025 10:32:30 GMT
Subject: RFR: 8373335: Serial: Clean up SerialHeap members by access
 specifies [v2]
In-Reply-To: <BTxeQWZwOIs3LmnqaD50xr5ZkN5F1kj-Wioa8bEKUAs=.5948906d-7352-4ba5-8b55-f9e6b74fdd6c@github.com>
References: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>
 <BTxeQWZwOIs3LmnqaD50xr5ZkN5F1kj-Wioa8bEKUAs=.5948906d-7352-4ba5-8b55-f9e6b74fdd6c@github.com>
Message-ID: <UM2-tshHz28fVYzhqHSYPiUrSAqlED4v7PO2jwMInE0=.447bbd3b-89e2-417a-9655-26b3a20eae31@github.com>

On Tue, 9 Dec 2025 09:33:27 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> These two member variables are not initialized in the constructor like all other member variables

Fixed.

> The implementation order for most methods in serialHeap.cpp is quite different from the declaration/definition order in serialHeap.hpp, which is something we might also want to fix.

Filed a new ticket: https://bugs.openjdk.org/browse/JDK-8373339

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

PR Comment: https://git.openjdk.org/jdk/pull/28718#issuecomment-3631486175

From jsikstro at openjdk.org  Tue Dec  9 11:00:56 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 9 Dec 2025 11:00:56 GMT
Subject: RFR: 8373335: Serial: Clean up SerialHeap members by access
 specifies [v2]
In-Reply-To: <DD9aV2kL8autSQHgUH1Mf2ndxvmsErJmWxr0gUgjJT4=.0fce4b73-b92d-486c-97b8-6b4d63d4fe41@github.com>
References: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>
 <DD9aV2kL8autSQHgUH1Mf2ndxvmsErJmWxr0gUgjJT4=.0fce4b73-b92d-486c-97b8-6b4d63d4fe41@github.com>
Message-ID: <jUA1nvRMUbAeJ3vpdOSkWkihlUcg9Yxvn4k-NyWdXfA=.223e3cd5-bdb0-4b99-9bbd-2ab875bf4833@github.com>

On Tue, 9 Dec 2025 10:28:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial moving member of `SerialHeap` so that all `private` fields/methods are altogether (at the top).
>>  
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by jsikstro (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28718#pullrequestreview-3556766442

From lkorinth at openjdk.org  Tue Dec  9 13:47:24 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 9 Dec 2025 13:47:24 GMT
Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future changes
Message-ID: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com>

This PR slightly changes when we may `InjectGCWorkerCreationFailure`.  At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993,  create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads.

This change should not change the current behaviour. But help future improvements.

I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge.

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

Commit messages:
 - 8373253: Re-work InjectGCWorkerCreationFailure for future changes

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

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

From btaylor at openjdk.org  Tue Dec  9 17:50:25 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Tue, 9 Dec 2025 17:50:25 GMT
Subject: RFR: 8352914: Shenandoah: Change definition of
 ShenandoahSharedValue to int32_t to leverage platform atomics
In-Reply-To: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
References: <32HM2TBQGO0hbc42x3mah4v-JKwYZo7YiVNjrmc1r5M=.949fb4f6-5882-4c30-b9b6-e0adc7deca79@github.com>
Message-ID: <Hzu4YHa7y8io6NxHB6SFhDE_b4WNFSGZqitWx_-8P9s=.81c1ed77-69bc-4d12-a8bb-4a2eadcae57e@github.com>

On Fri, 5 Dec 2025 18:44:08 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> The `STATIC_ASSERT` below this typedef appears to be out of date. 
> 
> The barriers check thread local copy of gc state, which is stored in `ShenandoahThreadLocalData::_gc_state`  and is type `char`, so the size requirement described by the assert is maintained even after this change.
> 
> Change passes all tier1 tests locally when run with Shenandoah GC.

In SpecJBB 2015, I observed the following performance changes. These comparisons are only between single runs, so some variance should be expected.

On aarch64:
- Critical jops increased from 57513 to 57779, (+266 / +0.46%)
- Max jops increased from 62164 to 53015 (+851 / +1.36%)

On x86_64:
- Critical jops increased from 86241 to 92047 (+5806 / 6.73%)
- Max jops increased from 88479 to 95613 (+7134 / +8.06%)

I also ran dacapo and specjvm, but no other results in any of the 3 benchmarks showed significant changes. Most other results were within 0.5% or less

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

PR Comment: https://git.openjdk.org/jdk/pull/28681#issuecomment-3633443138

From wkemper at openjdk.org  Tue Dec  9 18:15:08 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 9 Dec 2025 18:15:08 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v13]
In-Reply-To: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
Message-ID: <YAtwdYV53oiU0MzdmEy_CH9PpBrzGv3vzbkEmIBEux8=.22e91da6-c4b5-4989-9f77-56744a92f11c@github.com>

> Notable changes:
> * Improvements to logging
> * More accurate tracking of promotion failures
> * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size)
> * Use census information gathered during mark to size promotion reserves and old generation
> 
> With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results.
> 
> Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks:
> 
> 
> Concurrent Evacuation: 7 improvements, 3 regressions
> ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%)
> ? Worst regression: xalan (+53.7%)
> 
> Concurrent Marking: 15 improvements, 1 regression  
> ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%)
> ? Only regression: serial (+8.9%)
> 
> Concurrent Scan Remembered Set: 7 improvements, 2 regressions
> ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%)
> ? Worst regression: extremem-phased (+52.4%)
> 
> Concurrent Update Refs: 5 improvements, 4 regressions
> ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%)
> ? Worst regression: xalan (+89.4%)

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

 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Fix comments, add back an assertion
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Accommodate behavior of global heuristic
 - Restore missing update for inplace promotion padding
 - Remove reference to adaptive tuning flag
 - Remove commented out assertion
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Adaptive tenuring is no longer optional
   
   We are using age census data to compute promotion reserves. The tenuring threshold may still be fixed by setting the min/max threshold to the same value.
 - Remove bad asserts
 - ... and 70 more: https://git.openjdk.org/jdk/compare/b99be505...0869a46a

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

Changes: https://git.openjdk.org/jdk/pull/27632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=12
  Stats: 398 lines in 11 files changed: 158 ins; 173 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/27632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27632/head:pull/27632

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

From xpeng at openjdk.org  Tue Dec  9 18:22:46 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 9 Dec 2025 18:22:46 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v17]
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <DFs-q7t_5bacm14asqSCve__P0URSge_dMKMI_VNdts=.bc8803fe-de47-4af1-b897-d6162db39303@github.com>

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code:
> 
> * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class.
> * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and  `_yield_to_safepoint` to customize the allocator for mutator.
> * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. 
> * ShenandoahOldCollectorAllocator:  allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector`
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. 
> 
> java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> 
> 
> Openjdk TIP:
> 
> ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 2...

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Some comments updates as suggested in PR review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26171/files
  - new: https://git.openjdk.org/jdk/pull/26171/files/06366b4b..5e660216

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

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

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

From xpeng at openjdk.org  Tue Dec  9 18:48:35 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 9 Dec 2025 18:48:35 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
 <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
Message-ID: <P_nENWIbI3z2hgl57hfnPuFYA1R1Hks5COqrAwfpH8Q=.ee73d491-2f04-414a-963b-278e65371b29@github.com>

On Tue, 2 Dec 2025 22:04:06 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 pull request now contains 255 commits:
>> 
>>  - Add missing header for ShenandoahFreeSetPartitionId
>>  - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
>>  - Fix a typo
>>  - Remove unnecessary `enum class ShenandoahFreeSetPartitionId : uint8_t` in shenandoahAllocator.php
>>  - Make ShenandoahAllocator as template class to make compiled code more efficient for each alloc partition
>>  - Port the fix of JDK-8372566
>>  - Merge branch 'master' into cas-alloc-1
>>  - Merge remote-tracking branch 'origin/master' into cas-alloc-1
>>  - Remove junk code
>>  - Remove unnecessary change and tidy up
>>  - ... and 245 more: https://git.openjdk.org/jdk/compare/79e99bb0...7980c039
>
> src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 155:
> 
>> 153:   size_t min_free_words = req.is_lab_alloc() ? req.min_size() : req.size();
>> 154:   ShenandoahHeapRegion* r = _free_set->find_heap_region_for_allocation(ALLOC_PARTITION, min_free_words, req.is_lab_alloc(), in_new_region);
>> 155:   // The region returned by find_heap_region_for_allocation must have sufficient free space for the allocation it if it is not nullptr
> 
> comment has an extra "it"

fixed.

> src/hotspot/share/gc/shenandoah/shenandoahAllocator.hpp line 69:
> 
>> 67: 
>> 68:   // Attempt to allocate in shared alloc regions, the allocation attempt is done with atomic operation w/o
>> 69:   // holding heap lock.
> 
> I would rewrite comment:
> // Attempt to allocate in a shared alloc region using atomic operation without holding the heap lock.
> // Returns nullptr and overwrites regions_ready_for_refresh with the number of shared alloc regions that are ready
> // to be retired if it is unable to satisfy the allocation request from the existing shared alloc regions.

Thanks, I have updated the the comments as you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2603910894
PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2603909318

From kdnilsen at openjdk.org  Tue Dec  9 19:13:34 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 19:13:34 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v3]
In-Reply-To: <9gzZlrEzwroH2F-yEC6uzYIPsoKEcTBs_6UZDNFvvCg=.e0e0697f-e537-41fb-9f7f-740acbab4ad1@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <9gzZlrEzwroH2F-yEC6uzYIPsoKEcTBs_6UZDNFvvCg=.e0e0697f-e537-41fb-9f7f-740acbab4ad1@github.com>
Message-ID: <Hh1bz5h1gKxwfnOd4DMv3R6UTp9w4PZwIMHcFIfuTXM=.77591518-df07-474a-a495-c4666a2f839c@github.com>

On Tue, 9 Dec 2025 03:12:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
>> 
>> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.
>
> Kelvin Nilsen 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 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers-gh
>  - Add comment to describe behavior of adjust_old_garbage_threshold()
>  - Simplify representation of growth percentages
>  - Change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>  - make old evac ratio adaptive
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - Adjust test for new defaults
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/92ea7c4d...c7c22974

I reran the performance results following changes suggested by reviewers with similar results:
<img width="2185" height="191" alt="image" src="https://github.com/user-attachments/assets/c6f13150-f946-4065-b902-45c260357951" />

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

PR Comment: https://git.openjdk.org/jdk/pull/28561#issuecomment-3633865135

From xpeng at openjdk.org  Tue Dec  9 19:13:44 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 9 Dec 2025 19:13:44 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v14]
In-Reply-To: <HZ09NfolFLPIA8BX7cIcGHiOeCwGYI8RCP920lbKCzI=.c320081a-6730-434b-9a12-b2a414023dcb@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <K7WygjcKXD3XhnXE8pPj_GuZ-nxX5qc0jMWNLf8AC7A=.61f941cd-1552-418f-b192-d58245344dd9@github.com>
 <_mkL6HrCqlS1_qgOmXvEj3vsYgo2idQnbaDdMVFEGUk=.9c71f705-1f96-441e-96d0-c99d3053cffd@github.com>
 <30wgBRAA7e-TzwsWTFagwcJdAxRcOeFD6-WJS-ashhA=.05995833-528a-4dec-820f-0307bf769520@github.com>
 <HZ09NfolFLPIA8BX7cIcGHiOeCwGYI8RCP920lbKCzI=.c320081a-6730-434b-9a12-b2a414023dcb@github.com>
Message-ID: <pyK-L_B5R6E70MUUIQHPRwL4HB3iZYtE9ptdXXovctA=.e3c6364e-f0b7-4dfa-a117-47cfa7993df8@github.com>

On Wed, 3 Dec 2025 01:06:29 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> I suppose we could use conservative values for a first implementation, as long as we file a "low priority" ticket to come back and revisit for improved efficiency at a later time.
>
> We don't really know what need to be recompute until the allocation finishes, we can make it less  conservative, but then we needs more code branches here because the template methods require explicit template parameters.
> 
> I'll create to ticket to follow up on this, given that I also want to see if we can defer the recomputation to the read side, if we can do that we don't even need the ShenandoahHeapAccountingUpdater here.

I have created a bug for the improvement of accounting update: https://bugs.openjdk.org/browse/JDK-8373371

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2604001291

From kdnilsen at openjdk.org  Tue Dec  9 19:19:06 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 19:19:06 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v3]
In-Reply-To: <9gzZlrEzwroH2F-yEC6uzYIPsoKEcTBs_6UZDNFvvCg=.e0e0697f-e537-41fb-9f7f-740acbab4ad1@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <9gzZlrEzwroH2F-yEC6uzYIPsoKEcTBs_6UZDNFvvCg=.e0e0697f-e537-41fb-9f7f-740acbab4ad1@github.com>
Message-ID: <abTkRUnDs73QRnrhx1XONwew__QD_QnjgOVcLVCbXv8=.d091b444-4b32-46ad-aa44-9d500b045d25@github.com>

On Tue, 9 Dec 2025 03:12:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
>> 
>> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.
>
> Kelvin Nilsen 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 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers-gh
>  - Add comment to describe behavior of adjust_old_garbage_threshold()
>  - Simplify representation of growth percentages
>  - Change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>  - make old evac ratio adaptive
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - Adjust test for new defaults
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/107e9e49...c7c22974

The outlier in trial 4 results from a late trigger, after 4.529s of GC idle time.  This late trigger caused us to experience an allocation failure during marking, resulting in a stop-the-world degenerated pause of 188.556 ms.  Other development efforts will mitigate issues with late triggering.

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

PR Comment: https://git.openjdk.org/jdk/pull/28561#issuecomment-3633883006

From xpeng at openjdk.org  Tue Dec  9 21:06:29 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 9 Dec 2025 21:06:29 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v17]
In-Reply-To: <DFs-q7t_5bacm14asqSCve__P0URSge_dMKMI_VNdts=.bc8803fe-de47-4af1-b897-d6162db39303@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
 <DFs-q7t_5bacm14asqSCve__P0URSge_dMKMI_VNdts=.bc8803fe-de47-4af1-b897-d6162db39303@github.com>
Message-ID: <2YVE3uR8bRJ_8qAtXN4WoRmeY0Y9xhzsmKbxqv5oL2M=.2811f02e-35b8-46cf-863a-db4006ca1a78@github.com>

On Tue, 9 Dec 2025 18:22:46 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code:
>> 
>> * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class.
>> * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and  `_yield_to_safepoint` to customize the allocator for mutator.
>> * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. 
>> * ShenandoahOldCollectorAllocator:  allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector`
>> 
>> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance:
>> 
>> 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. 
>> 
>> java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
>> 
>> 
>> Openjdk TIP:
>> 
>> ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events =====
>> ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events =====
>> ===== DaCapo tail ...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some comments updates as suggested in PR review

src/hotspot/share/gc/shenandoah/shenandoahAllocator.cpp line 41:

> 39:   _alloc_region_count(alloc_region_count), _free_set(free_set), _alloc_partition_name(ShenandoahRegionPartitions::partition_name(ALLOC_PARTITION)) {
> 40:   if (alloc_region_count > 0) {
> 41:     _alloc_regions = PaddedArray<ShenandoahAllocRegion, mtGC>::create_unfreeable(alloc_region_count);

Rethinking about the the PaddedArray used here, we may not really need it.
Allocator has multiple shared alloc regions for CAS, and only refreshes them when all of them run out of usable memory, so _alloc_regions won't be frequently updated, the PaddedArray here should have a negative performance impact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2604362492

From duke at openjdk.org  Tue Dec  9 22:48:44 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 9 Dec 2025 22:48:44 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect [v3]
In-Reply-To: <KTbfuDFNvt67B8JT7qca1auyuZn_dfDRhmvOsrE9uAc=.a4fec091-b4e7-4f19-9b9d-aa3e0ee09438@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
 <nDhDGPSvzovYIsAP0jKr311TFj72ZzxR72UkkcofcVk=.cfd87dcc-1f74-4445-9be9-4f3ae1fbc478@github.com>
 <KTbfuDFNvt67B8JT7qca1auyuZn_dfDRhmvOsrE9uAc=.a4fec091-b4e7-4f19-9b9d-aa3e0ee09438@github.com>
Message-ID: <pr6GX6Wmm6lt4d_stOFFFJPM-9k8odnSIyjlqN3lBi8=.1b68cf59-f323-4008-abdd-2f655bacdf6e@github.com>

On Fri, 5 Dec 2025 19:34:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused freeset includes
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 940:
> 
>> 938: 
>> 939: size_t ShenandoahGeneration::soft_available_exclude_evac_reserve() const {
>> 940:   size_t result = available(ShenandoahHeap::heap()->soft_max_capacity() * (100.0 - ShenandoahEvacReserve) / 100);
> 
> I'm a little uncomfortable with this approach.  It's mostly a question of how we name it.  The evac reserve is not always this value.  In particular, we may shrink the young evac reserves after we have selected the cset.  Also of concern is that if someone invokes this function on old_generation(), it looks like they'll get a bogus (not meaningful) value.
> 
> I think I'd be more comfortable with naming this to something like "mutator_available_when_gc_is_idle()".  If we keep it virtual, then OldGeneration should override with "assert(false, "Not relevant to old generation")

Talked offline. Rename this to `soft_mutator_available`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28622#discussion_r2604612374

From kdnilsen at openjdk.org  Tue Dec  9 22:55:48 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 22:55:48 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v3]
In-Reply-To: <9gzZlrEzwroH2F-yEC6uzYIPsoKEcTBs_6UZDNFvvCg=.e0e0697f-e537-41fb-9f7f-740acbab4ad1@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <9gzZlrEzwroH2F-yEC6uzYIPsoKEcTBs_6UZDNFvvCg=.e0e0697f-e537-41fb-9f7f-740acbab4ad1@github.com>
Message-ID: <IHILqGB01k3U2I87JkJZRT9UKpJ4E8PHKFPptZG5Nnw=.b9008484-d6b3-4a93-9e61-fec995aa0eb6@github.com>

On Tue, 9 Dec 2025 03:12:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
>> 
>> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.
>
> Kelvin Nilsen 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 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers-gh
>  - Add comment to describe behavior of adjust_old_garbage_threshold()
>  - Simplify representation of growth percentages
>  - Change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>  - make old evac ratio adaptive
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - Adjust test for new defaults
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/08fdfe16...c7c22974

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 249:

> 247:     _live_bytes_after_last_mark + (_live_bytes_after_last_mark * _growth_percent_before_compaction) / 100;
> 248:   size_t threshold_by_growth_into_percent_remaining = (size_t)
> 249:     (_live_bytes_after_last_mark + ((ShenandoahHeap::heap()->soft_max_capacity() - _live_bytes_after_last_mark)

I need to protect against underflow here.  It might be that _live_bytes_after_last_mark is greater than soft_max_capacity().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2604625802

From duke at openjdk.org  Tue Dec  9 23:16:35 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 9 Dec 2025 23:16:35 GMT
Subject: RFR: 8372543: Shenandoah: undercalculated the available size when
 soft max takes effect [v4]
In-Reply-To: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
References: <xhjPuqPrTm0qZ7TCq2Yrt8zCU655xlp5-ApBJYs-n0Y=.fae88ac6-c542-415a-a8f3-64a1e148bdf8@github.com>
Message-ID: <F2_4FOVcNXNtftsehkwPN2X3fH9ZrJv8mz8pnyVLUYs=.061e3075-7dae-4ca4-9aa1-3f2212cd94b2@github.com>

> Detailed math and repro see https://bugs.openjdk.org/browse/JDK-8372543. 
> 
> Currently in shenandoah, when deciding whether to have gc, how we calculate available size is:
> 
> 
> available = (Xmx * (100 - ShenandoahEvacReserve) / 100) - used
> soft_tail = Xmx - soft_max
> if (available - soft_tail < ShenandoahMinFreeThreshold * soft_max) // trigger gc 
> 
> 
> The if condition `available - soft_tail` will be reduced to: `-(ShenandoahEvacReserve/100) * Xmx - used + soft_max`, which means when soft max is the same, the larger Xmx is, the less free size the app would have and the more gc it would have, which does not make sense, especially for the case where the app is mostly idle. This caused one of our internal customers experienced frequent gc with minimal workload, when soft max heap size was set way lower than Xmx.
> 
> 
> Suggested fix: when deciding when to trigger gc, use logic similar to below:
> 
> mutator_soft_capacity = soft_max * (100 - ShenandoahEvacReserve) / 100;
> available = mutator_soft_capacity - used;
> if (available < mutator_soft_capacity) // trigger gc
> ``` 
> 
> Tests:
> - Ran the repro app `StableLiveSet.java` in https://bugs.openjdk.org/browse/JDK-8372543. Without fix, tip had ~2910 times gc in 20 sec with `-XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=adaptive -XX:SoftMaxHeapSize=512m -Xmx31g` jvm args. With the fix, only 18 times in 20 sec.
> - GHA passed.
> 
> -------
> This change also improved gc logging:
> 
> Before:
> 
> [6.831s][info][gc          ] Trigger: Free (52230K) is below minimum threshold (52428K)
> [6.831s][info][gc,free     ] Free: 1587M, Max: 1024K regular, 1539M humongous, Frag: 2% 
> external, 18% internal; Used: 352M, Mutator Free: 1940 Collector Reserve: 103M, Max: 1024K; Used: 0B
> 
> 
> After:
> 
> [8.358s][info][gc          ] Trigger: Free (Soft mutator free) (51498K) is below minimum threshold (52428K)
> [8.358s][info][gc,free     ] Whole heap stats: Total free: 1509M, Total used: 401M, Max free in a single region: 
> 1024K, Max humongous: 1490M; Frag stats: External: 0%, Internal: 21%;  Mutator freeset stats: Partition count: 
> 1911, Reserved: 1509M, Max free available in a single region: 1024K; Collector freeset stats: Partition count: 
> 122, Reserved: 102M, Max free available in a single region: 1024K;

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

  log and naming fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28622/files
  - new: https://git.openjdk.org/jdk/pull/28622/files/599cc2d7..8dea5164

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

  Stats: 33 lines in 11 files changed: 0 ins; 14 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/28622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28622/head:pull/28622

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

From kdnilsen at openjdk.org  Tue Dec  9 23:21:39 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Dec 2025 23:21:39 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v4]
In-Reply-To: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
Message-ID: <XNApCPWM-nokDk9gu6pQBuQoPGZrDMT09MyyeLqcGqo=.76e5d732-60b2-4dc0-82a0-ba8554d456a9@github.com>

> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
> 
> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Protect against underflow when computing old growth trigger threshold

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28561/files
  - new: https://git.openjdk.org/jdk/pull/28561/files/c7c22974..79a21ee6

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

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

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

From xpeng at openjdk.org  Wed Dec 10 01:00:07 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 10 Dec 2025 01:00:07 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v18]
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <gi91ohMV1wMgOcCw66V98UGOu-KvqV8r1DFcsa4VxH0=.5b870da1-af2c-4ffc-bd18-6a4c8c46fb61@github.com>

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code:
> 
> * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class.
> * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and  `_yield_to_safepoint` to customize the allocator for mutator.
> * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. 
> * ShenandoahOldCollectorAllocator:  allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector`
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. 
> 
> java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> 
> 
> Openjdk TIP:
> 
> ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 2...

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 262 commits:

 - Merge branch 'master' into cas-alloc-1
 - Some comments updates as suggested in PR review
 - Fix build failure after merge
 - Expend promoted from ShenandoahOldCollectorAllocator
 - Merge branch 'master' into cas-alloc-1
 - Address PR comments
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Add missing header for ShenandoahFreeSetPartitionId
 - Declare ShenandoahFreeSetPartitionId as enum instead of enum class
 - Fix a typo
 - ... and 252 more: https://git.openjdk.org/jdk/compare/020e3f95...c8e98bce

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

Changes: https://git.openjdk.org/jdk/pull/26171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=17
  Stats: 1643 lines in 25 files changed: 1296 ins; 235 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

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

From mbaesken at openjdk.org  Wed Dec 10 09:04:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 10 Dec 2025 09:04:42 GMT
Subject: RFR: 8371420: Still sporadic failures of
 gc/TestAlwaysPreTouchBehavior.java#<gcname> on Linux after JDK-8359104
Message-ID: <R0y53QsPKcCXAOydrf8DdROUeDvMxivfTFCBBTnR6Eo=.794be77d-c2b0-4aeb-91cb-eca0ca59264a@github.com>

After [JDK-8359104](https://bugs.openjdk.org/browse/JDK-8359104) where getting RSS was improved, we still see sporadic failures of the test gc/TestAlwaysPreTouchBehavior.java#<gcname> , for different gcs.
E.g. gc/TestAlwaysPreTouchBehavior.java#Epsilon (with -Xlog:os=debug added for more output) 


----------System.err:(13/1278)----------
java.lang.RuntimeException: RSS of this process(24465408b) should be bigger than or equal to heap size(268435456b) (available memory: 16295006208). On Linux Kernel < 4.14 RSS can be inaccurate: expected 24465408 > 268435456


Looks like the RSS values we get are somewhat delayed/inaccurate .

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

Commit messages:
 - JDK-8371420

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

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

From manc at openjdk.org  Wed Dec 10 09:58:59 2025
From: manc at openjdk.org (Man Cao)
Date: Wed, 10 Dec 2025 09:58:59 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail with
 large G1HeapRegionSize and small InitialHeapSize
Message-ID: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>

Hi all,

Could anyone review this test-only improvement to make TestG1ClassUnloadingHWM.java more robust in various configurations?
See https://bugs.openjdk.org/browse/JDK-8373403 for more details.

-Man

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

Commit messages:
 - 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail with large G1HeapRegionSize and small InitialHeapSize

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

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

From mdoerr at openjdk.org  Wed Dec 10 10:11:31 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 Dec 2025 10:11:31 GMT
Subject: RFR: 8371420: Still sporadic failures of
 gc/TestAlwaysPreTouchBehavior.java#<gcname> on Linux after JDK-8359104
In-Reply-To: <R0y53QsPKcCXAOydrf8DdROUeDvMxivfTFCBBTnR6Eo=.794be77d-c2b0-4aeb-91cb-eca0ca59264a@github.com>
References: <R0y53QsPKcCXAOydrf8DdROUeDvMxivfTFCBBTnR6Eo=.794be77d-c2b0-4aeb-91cb-eca0ca59264a@github.com>
Message-ID: <Ai8Mk1vL8_YR9-hPXjZzxgx_uBFBzvO-JpK-Ygyr2-4=.d6fb9e49-2eed-4414-a4b8-723feaa455cc@github.com>

On Wed, 10 Dec 2025 08:57:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8359104](https://bugs.openjdk.org/browse/JDK-8359104) where getting RSS was improved, we still see sporadic failures of the test gc/TestAlwaysPreTouchBehavior.java#<gcname> , for different gcs.
> E.g. gc/TestAlwaysPreTouchBehavior.java#Epsilon (with -Xlog:os=debug added for more output) 
> 
> 
> ----------System.err:(13/1278)----------
> java.lang.RuntimeException: RSS of this process(24465408b) should be bigger than or equal to heap size(268435456b) (available memory: 16295006208). On Linux Kernel < 4.14 RSS can be inaccurate: expected 24465408 > 268435456
> 
> 
> Looks like the RSS values we get are somewhat delayed/inaccurate .

test/hotspot/jtreg/gc/TestAlwaysPreTouchBehavior.java line 136:

> 134: 
> 135:     public static void main(String [] args) {
> 136:         int maxIter = 20;

A comment would be helpful describing why we run it in a loop. Maybe "RSS values we get are somewhat delayed or inaccurate"?

test/hotspot/jtreg/gc/TestAlwaysPreTouchBehavior.java line 166:

> 164:                 break;
> 165:               }
> 166:             }

Java code should use 4 spaces indentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28735#discussion_r2606002728
PR Review Comment: https://git.openjdk.org/jdk/pull/28735#discussion_r2606005559

From iwalulya at openjdk.org  Wed Dec 10 12:05:22 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 10 Dec 2025 12:05:22 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize
In-Reply-To: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
Message-ID: <8B0_yF31fg2xJ1nPx4ZGq4MSbnMl73glvmJB3HBCSKA=.97b9be20-b788-4df0-bbfa-6cdfbb419668@github.com>

On Wed, 10 Dec 2025 09:48:44 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this test-only improvement to make TestG1ClassUnloadingHWM.java more robust in various configurations?
> See https://bugs.openjdk.org/browse/JDK-8373403 for more details.
> 
> -Man

The issue appears to be that we compute an IHOP target threshold that is smaller than the G1HeapRegionSize. So after the "Pause Full (Metadata GC Threshold)", a concurrent cycle is requested.

Would it be better to fix that as below?

--- a/src/hotspot/share/gc/g1/g1IHOPControl.cpp
+++ b/src/hotspot/share/gc/g1/g1IHOPControl.cpp
@@ -115,7 +115,7 @@ size_t G1IHOPControl::get_conc_mark_start_threshold() {
   guarantee(_target_occupancy > 0, "Target occupancy must be initialized");
 
   if (!_is_adaptive || !have_enough_data_for_prediction()) {
-    return (size_t)(_initial_ihop_percent * _target_occupancy / 100.0);
+    return MAX2((size_t)(_initial_ihop_percent * _target_occupancy / 100.0), G1HeapRegionSize);
   }

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

PR Comment: https://git.openjdk.org/jdk/pull/28738#issuecomment-3636758512

From mbaesken at openjdk.org  Wed Dec 10 12:34:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 10 Dec 2025 12:34:56 GMT
Subject: RFR: 8371420: Still sporadic failures of
 gc/TestAlwaysPreTouchBehavior.java#<gcname> on Linux after JDK-8359104 [v2]
In-Reply-To: <R0y53QsPKcCXAOydrf8DdROUeDvMxivfTFCBBTnR6Eo=.794be77d-c2b0-4aeb-91cb-eca0ca59264a@github.com>
References: <R0y53QsPKcCXAOydrf8DdROUeDvMxivfTFCBBTnR6Eo=.794be77d-c2b0-4aeb-91cb-eca0ca59264a@github.com>
Message-ID: <-bQqTnNto5bZsLggV61ChqBIgWE1crdtH6MqdYu5BQ8=.9890d66f-7b60-461a-8b42-31b861aeb6be@github.com>

> After [JDK-8359104](https://bugs.openjdk.org/browse/JDK-8359104) where getting RSS was improved, we still see sporadic failures of the test gc/TestAlwaysPreTouchBehavior.java#<gcname> , for different gcs.
> E.g. gc/TestAlwaysPreTouchBehavior.java#Epsilon (with -Xlog:os=debug added for more output) 
> 
> 
> ----------System.err:(13/1278)----------
> java.lang.RuntimeException: RSS of this process(24465408b) should be bigger than or equal to heap size(268435456b) (available memory: 16295006208). On Linux Kernel < 4.14 RSS can be inaccurate: expected 24465408 > 268435456
> 
> 
> Looks like the RSS values we get are somewhat delayed/inaccurate .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Add a comment about RSS values and adjust indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28735/files
  - new: https://git.openjdk.org/jdk/pull/28735/files/9eb19178..5fd2bbad

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

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

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

From ayang at openjdk.org  Wed Dec 10 13:05:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 10 Dec 2025 13:05:40 GMT
Subject: RFR: 8371420: Still sporadic failures of
 gc/TestAlwaysPreTouchBehavior.java#<gcname> on Linux after JDK-8359104 [v2]
In-Reply-To: <-bQqTnNto5bZsLggV61ChqBIgWE1crdtH6MqdYu5BQ8=.9890d66f-7b60-461a-8b42-31b861aeb6be@github.com>
References: <R0y53QsPKcCXAOydrf8DdROUeDvMxivfTFCBBTnR6Eo=.794be77d-c2b0-4aeb-91cb-eca0ca59264a@github.com>
 <-bQqTnNto5bZsLggV61ChqBIgWE1crdtH6MqdYu5BQ8=.9890d66f-7b60-461a-8b42-31b861aeb6be@github.com>
Message-ID: <VpBceliBtPNJyoZht9DOZLrDhvgTsVaAvZkeSdtKDws=.b3eb8bd7-c1d0-4ba8-b7ee-d70bf1ec5412@github.com>

On Wed, 10 Dec 2025 12:34:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After [JDK-8359104](https://bugs.openjdk.org/browse/JDK-8359104) where getting RSS was improved, we still see sporadic failures of the test gc/TestAlwaysPreTouchBehavior.java#<gcname> , for different gcs.
>> E.g. gc/TestAlwaysPreTouchBehavior.java#Epsilon (with -Xlog:os=debug added for more output) 
>> 
>> 
>> ----------System.err:(13/1278)----------
>> java.lang.RuntimeException: RSS of this process(24465408b) should be bigger than or equal to heap size(268435456b) (available memory: 16295006208). On Linux Kernel < 4.14 RSS can be inaccurate: expected 24465408 > 268435456
>> 
>> 
>> Looks like the RSS values we get are somewhat delayed/inaccurate .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about RSS values and adjust indentation

Looks reasonable. I wonder if it makes sense to extract the loop-body into a method so that the retrying logic are not intertwined with each attempt.

Additionally, there seems a preexisting issue that the else branch of `(available > requiredAvailable)` should probably also throw `SkippedException`?

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

PR Review: https://git.openjdk.org/jdk/pull/28735#pullrequestreview-3562444765

From ayang at openjdk.org  Wed Dec 10 13:12:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 10 Dec 2025 13:12:40 GMT
Subject: RFR: 8373335: Serial: Clean up SerialHeap members by access
 specifies [v2]
In-Reply-To: <DD9aV2kL8autSQHgUH1Mf2ndxvmsErJmWxr0gUgjJT4=.0fce4b73-b92d-486c-97b8-6b4d63d4fe41@github.com>
References: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>
 <DD9aV2kL8autSQHgUH1Mf2ndxvmsErJmWxr0gUgjJT4=.0fce4b73-b92d-486c-97b8-6b4d63d4fe41@github.com>
Message-ID: <YfitII0zDFZd9WxiBnHTCz4YHe_LzCVO85MJavfqBB8=.2a08c3b2-5ac3-4de9-8c12-9f552fe61a87@github.com>

On Tue, 9 Dec 2025 10:28:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial moving member of `SerialHeap` so that all `private` fields/methods are altogether (at the top).
>>  
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28718#issuecomment-3637013763

From ayang at openjdk.org  Wed Dec 10 13:12:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 10 Dec 2025 13:12:42 GMT
Subject: Integrated: 8373335: Serial: Clean up SerialHeap members by access
 specifies
In-Reply-To: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>
References: <9jYRuzaSgrYnTjPonMqHiiqKmqOQSsJtsOBIP3dlIzI=.22dc5083-63b1-4839-be0d-759cd01f650b@github.com>
Message-ID: <wurlRYjXkpKHA2cVLHRVTeq4_GzlLPTvtcWIUFHd_QM=.43350f52-990b-44df-ab84-9e541420b371@github.com>

On Tue, 9 Dec 2025 09:08:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial moving member of `SerialHeap` so that all `private` fields/methods are altogether (at the top).
>  
> Test: tier1

This pull request has now been integrated.

Changeset: 655e9cda
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/655e9cda3f6b1fa3a6f0553e7745aa088dde53e8
Stats:     44 lines in 2 files changed: 22 ins; 21 del; 1 mod

8373335: Serial: Clean up SerialHeap members by access specifies

Reviewed-by: jsikstro

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

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

From ayang at openjdk.org  Wed Dec 10 13:18:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 10 Dec 2025 13:18:41 GMT
Subject: RFR: 8373421: Parallel: Rename young generation eden and survivor
 space pool
Message-ID: <MO1KogXIlCHwgeKjpjFe5cQhM6d9x2SBbKvFIXIZXlU=.698b10a2-7987-435a-9d8d-a35b74c5bfd5@github.com>

Trivial renaming two `*SpacePool` classes:


EdenMutableSpacePool -> PSEdenSpacePool
SurvivorMutableSpacePool -> PSSurvivorSpacePool

Test: tier1

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

Commit messages:
 - pgc-space-pool-rename

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

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

From tschatzl at openjdk.org  Wed Dec 10 13:54:48 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 10 Dec 2025 13:54:48 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize
In-Reply-To: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
Message-ID: <fTtyydCO4BkW6fp19IVDVEdgAdZkSb1w-c-eojTdAok=.800ee172-54e1-4ae6-b6cf-f6df150bfeb1@github.com>

On Wed, 10 Dec 2025 09:48:44 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this test-only improvement to make TestG1ClassUnloadingHWM.java more robust in various configurations?
> See https://bugs.openjdk.org/browse/JDK-8373403 for more details.
> 
> -Man

I think this is a test bug: it should check whether the Metadata GCs is a full gc and not a young gc starting a concurrent mark. Right now the test just checks whether there is any full gc and not a concurrent start gc at all. The regexp should add a `?Metadata GC Threshold` part there.

@walulyai' s comment hints at another issue: if there is only one region, there is no gain in collecting that region (unless, very unlikely, that single region is completely empty). Either the concurrent mark will select it as an evacuation candidate and copy its contents to another (single) region, or do nothing.

Either way nothing is gained. However this is a different issue imo.

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

PR Comment: https://git.openjdk.org/jdk/pull/28738#issuecomment-3637194010

From eastigeevich at openjdk.org  Wed Dec 10 15:09:30 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 10 Dec 2025 15:09:30 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v15]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <wQCvqP2QoXY5enNEuFFEKyt2r3Ae9bJWYaFGGvAzuJ4=.b3404fbb-fae4-43d6-81bc-97fa5f8e45da@github.com>

> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>  
> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
> - Disable coherent icache.
> - Trap IC IVAU instructions.
> - Execute:
>    - `tlbi vae3is, xzr`
>    - `dsb sy`
>  
>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>  
> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
> 
> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
> 
> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
> 
> Changes include:
> 
> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2), 5 000 nmethods, 1 parallel thread, 1 concurrent thread, 3 forks, ms/op (lower better)
> 
> - ZGC
> 
> | Benchmark | accessedFieldCount | Baseline | Error (Baseline) | Fix | ...

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

  Fix tier1 failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/b9380fd8..85691beb

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

  Stats: 69 lines in 10 files changed: 27 ins; 31 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28328.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328

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

From tschatzl at openjdk.org  Wed Dec 10 15:30:09 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 10 Dec 2025 15:30:09 GMT
Subject: RFR: 8372860: TestCodeCacheUnloadDuringConcCycle fails on ARM32
In-Reply-To: <jOhw4WTUFb4J1NVe0sRvSE0PRcCh67-ZUPmSS5c8ACo=.d22e03cd-b293-441c-b99c-7c12dbc6acf8@github.com>
References: <jOhw4WTUFb4J1NVe0sRvSE0PRcCh67-ZUPmSS5c8ACo=.d22e03cd-b293-441c-b99c-7c12dbc6acf8@github.com>
Message-ID: <htav8Tj7NK-Rjx5konoLdZfJsOYTIwyQ-T5_KWpH_1o=.3c4f58a2-1224-470a-82f4-ff2ef46c280a@github.com>

On Wed, 10 Dec 2025 10:54:33 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> Increasing number of iterations in the test, to give it a chance to fill CodeCache enough to reach the required threshold to trigger CodeCache GC on Linux-aarch32.
> 
> The time of the test is increased, but it seems still reasonable. (15s --> 35s on my laptop, linux64)
> 
> I confirm that this fix makes the test passed on linux-aarch32.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28742#pullrequestreview-3563132008

From duke at openjdk.org  Wed Dec 10 15:59:29 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Dec 2025 15:59:29 GMT
Subject: RFR: 8372860: TestCodeCacheUnloadDuringConcCycle fails on ARM32
In-Reply-To: <jOhw4WTUFb4J1NVe0sRvSE0PRcCh67-ZUPmSS5c8ACo=.d22e03cd-b293-441c-b99c-7c12dbc6acf8@github.com>
References: <jOhw4WTUFb4J1NVe0sRvSE0PRcCh67-ZUPmSS5c8ACo=.d22e03cd-b293-441c-b99c-7c12dbc6acf8@github.com>
Message-ID: <ZcR_dPSSYPRU0Rrmo9ITygIAVFisM9pSgRRWvBhcNzc=.f12806bc-04a9-4f79-add1-b0945c86584b@github.com>

On Wed, 10 Dec 2025 10:54:33 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> Increasing number of iterations in the test, to give it a chance to fill CodeCache enough to reach the required threshold to trigger CodeCache GC on Linux-aarch32.
> 
> The time of the test is increased, but it seems still reasonable. (15s --> 35s on my laptop, linux64)
> 
> I confirm that this fix makes the test passed on linux-aarch32.

@wkia 
Your change (at version 0af5da001fd84b82cf4f09c02b257dd9aa2691a7) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28742#issuecomment-3637778398

From tschatzl at openjdk.org  Wed Dec 10 16:18:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 10 Dec 2025 16:18:07 GMT
Subject: RFR: 8373421: Parallel: Rename young generation eden and survivor
 space pool
In-Reply-To: <MO1KogXIlCHwgeKjpjFe5cQhM6d9x2SBbKvFIXIZXlU=.698b10a2-7987-435a-9d8d-a35b74c5bfd5@github.com>
References: <MO1KogXIlCHwgeKjpjFe5cQhM6d9x2SBbKvFIXIZXlU=.698b10a2-7987-435a-9d8d-a35b74c5bfd5@github.com>
Message-ID: <r_9xTA-aR3pvTQgrvaakMpbPfqUPMDdNQ27j9b7NkK8=.53d0a305-8238-4468-9318-5db8f6da6dcc@github.com>

On Wed, 10 Dec 2025 13:11:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial renaming two `*SpacePool` classes:
> 
> 
> EdenMutableSpacePool -> PSEdenSpacePool
> SurvivorMutableSpacePool -> PSSurvivorSpacePool
> 
> Test: tier1

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28744#pullrequestreview-3563372200

From tschatzl at openjdk.org  Wed Dec 10 16:21:15 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 10 Dec 2025 16:21:15 GMT
Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future
 changes
In-Reply-To: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com>
References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com>
Message-ID: <fztpAukI228xzpOoE7hPWdzfk9pXB9YpAD2kWtkutsY=.2ad04da1-ee40-4669-9724-977c61909e92@github.com>

On Tue, 9 Dec 2025 13:39:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This PR slightly changes when we may `InjectGCWorkerCreationFailure`.  At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993,  create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads.
> 
> This change should not change the current behaviour. But help future improvements.
> 
> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28719#pullrequestreview-3563386085

From ysr at openjdk.org  Wed Dec 10 16:51:05 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 10 Dec 2025 16:51:05 GMT
Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v5]
In-Reply-To: <Ge-zZoIg1nkufj7LhD6BgeWAryy8BrKd4GcvYDqF_0g=.c2b2cdd5-f722-4e9d-b89f-d6eb192a058f@github.com>
References: <a9W__FkIse8vp8IcikVXQPYrzrqoPoMmtGbBad4U-L0=.6d55276d-15aa-44f7-b2ec-0031d4da77ec@github.com>
 <Ge-zZoIg1nkufj7LhD6BgeWAryy8BrKd4GcvYDqF_0g=.c2b2cdd5-f722-4e9d-b89f-d6eb192a058f@github.com>
Message-ID: <uehcx_zk5OXcOySYfc499WTMGv18Spvx053_t8B9_R8=.cf10fce8-6013-4791-a6b4-8768690f3a18@github.com>

On Wed, 19 Nov 2025 23:31:41 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Exclude young-young, old-old and honor UseCondCardMark in dirty card marking.
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   hardening of comments
>   
>   remove unintended files

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28204#pullrequestreview-3563535274

From shade at openjdk.org  Wed Dec 10 16:54:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Dec 2025 16:54:52 GMT
Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v5]
In-Reply-To: <Ge-zZoIg1nkufj7LhD6BgeWAryy8BrKd4GcvYDqF_0g=.c2b2cdd5-f722-4e9d-b89f-d6eb192a058f@github.com>
References: <a9W__FkIse8vp8IcikVXQPYrzrqoPoMmtGbBad4U-L0=.6d55276d-15aa-44f7-b2ec-0031d4da77ec@github.com>
 <Ge-zZoIg1nkufj7LhD6BgeWAryy8BrKd4GcvYDqF_0g=.c2b2cdd5-f722-4e9d-b89f-d6eb192a058f@github.com>
Message-ID: <My4wLmntvsoNnRF8cTxoNI4Q92mvL5ryUTOnZNfh5Bs=.d8afe180-39c4-4fe3-bdc2-5925911c6449@github.com>

On Wed, 19 Nov 2025 23:31:41 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Exclude young-young, old-old and honor UseCondCardMark in dirty card marking.
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   hardening of comments
>   
>   remove unintended files

I am good with comments as they are. Thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28204#pullrequestreview-3563550852

From ysr at openjdk.org  Wed Dec 10 16:54:54 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 10 Dec 2025 16:54:54 GMT
Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v3]
In-Reply-To: <uiDsBW2SIe3Lb4WuQh12PDltDvLMTcGeY9Ohfyb0d-g=.51f1e77e-a8e1-4b65-8dd9-57c0aca33c7d@github.com>
References: <a9W__FkIse8vp8IcikVXQPYrzrqoPoMmtGbBad4U-L0=.6d55276d-15aa-44f7-b2ec-0031d4da77ec@github.com>
 <-0iMsHeZnk_Ld_6D9zCBNFVcXi9rIq9S0NmmYEgqb0I=.ffb1591a-83a7-47be-86ff-a5646b51e3e1@github.com>
 <uiDsBW2SIe3Lb4WuQh12PDltDvLMTcGeY9Ohfyb0d-g=.51f1e77e-a8e1-4b65-8dd9-57c0aca33c7d@github.com>
Message-ID: <-92CnLR8zJxFhPPoimnzjae5ox6WSUh9YV1f4d5m4OI=.7a0eedf8-3ef6-4e4b-9d69-989d3e8014d2@github.com>

On Tue, 18 Nov 2025 23:06:47 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>
> Here are GenShen results over 100+ sample collections
> 
> +1.90% philosophers/philosophers_duration p=0.00142 (Wilcoxon)
>   Control:      2.620s  (+/-173.82ms)        120
>   Test:         2.670s  (+/-205.24ms)        120
> 
> +1.68% finagle-chirper/finagle-chirper_duration p=0.00343 (Wilcoxon)
>   Control:      2.802s  (+/-130.38ms)        360
>   Test:         2.850s  (+/-131.25ms)        360
> 
> +1.04% rx-scrabble/rx-scrabble_duration p=0.00000 (Wilcoxon)
>   Control:    148.308ms (+/-  0.88ms)        320
>   Test:       149.855ms (+/-  0.60ms)        320
> 
> -2.48% scrabble/scrabble_duration p=0.00000 (Wilcoxon)
>   Control:    169.599ms (+/-  2.90ms)        200
>   Test:       165.399ms (+/-  3.40ms)        200
> 
> -2.24% scala-kmeans/scala-kmeans_duration p=0.00000 (Wilcoxon)
>   Control:    479.973ms (+/-  1.92ms)        200
>   Test:       469.219ms (+/-  1.98ms)        200

@nityarai08 : 

> Description states:
> 
> > Exclude young-young, old-old and honor UseCondCardMark in dirty card marking.
> 
> I don't see any change for the latter. I believe `UseCondCardMark` is already enabled with GenShen, and the barrier ode respects it.
> 
> Also `Exclude young-young, old-old` skips the part of the change that also skips `young->old`. I'd reword the synopsis to:
> 
> > Skips card marks for stores in young generation objects, old -> old, and null stores.
> 
> which I think is what the code does.
> 

Once description/synopsis is corrected, this PR looks good to go. Approved in anticipation.

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

PR Comment: https://git.openjdk.org/jdk/pull/28204#issuecomment-3638042985

From shade at openjdk.org  Wed Dec 10 16:55:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Dec 2025 16:55:50 GMT
Subject: RFR: 8372860: TestCodeCacheUnloadDuringConcCycle fails on ARM32
In-Reply-To: <jOhw4WTUFb4J1NVe0sRvSE0PRcCh67-ZUPmSS5c8ACo=.d22e03cd-b293-441c-b99c-7c12dbc6acf8@github.com>
References: <jOhw4WTUFb4J1NVe0sRvSE0PRcCh67-ZUPmSS5c8ACo=.d22e03cd-b293-441c-b99c-7c12dbc6acf8@github.com>
Message-ID: <2lPu_i3QHe2_oQ7vAoCb2OZQocEyjS_zEu52x6OC3IQ=.eac91eba-06d7-4b8d-9d2d-a6a9e50f2da6@github.com>

On Wed, 10 Dec 2025 10:54:33 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> Increasing number of iterations in the test, to give it a chance to fill CodeCache enough to reach the required threshold to trigger CodeCache GC on Linux-aarch32.
> 
> The time of the test is increased, but it seems still reasonable. (15s --> 35s on my laptop, linux64)
> 
> I confirm that this fix makes the test passed on linux-aarch32.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28742#pullrequestreview-3563552351

From xpeng at openjdk.org  Wed Dec 10 17:07:37 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 10 Dec 2025 17:07:37 GMT
Subject: [jdk26] RFR: 8373116: Genshen: arraycopy_work should be always done
 for arrays in old gen during young concurrent marking
Message-ID: <fm5g78BYrCWtkUxsPrmpai8prFmEM-L9B3xPrxNwgZk=.f0bd81e2-eb83-47dc-9bc4-34f9fc824879@github.com>

Hi all,

This pull request contains a clean backport of commit [c9ab330b](https://github.com/openjdk/jdk/commit/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Xiaolong Peng on 9 Dec 2025 and was reviewed by William Kemper and Kelvin Nilsen.

It is a necessary bug fix to address the crash caused by recently change to arraycopy barrier. 

Thanks!

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

Commit messages:
 - Backport c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3

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

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

From shade at openjdk.org  Wed Dec 10 17:11:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Dec 2025 17:11:30 GMT
Subject: [jdk26] RFR: 8373116: Genshen: arraycopy_work should be always
 done for arrays in old gen during young concurrent marking
In-Reply-To: <fm5g78BYrCWtkUxsPrmpai8prFmEM-L9B3xPrxNwgZk=.f0bd81e2-eb83-47dc-9bc4-34f9fc824879@github.com>
References: <fm5g78BYrCWtkUxsPrmpai8prFmEM-L9B3xPrxNwgZk=.f0bd81e2-eb83-47dc-9bc4-34f9fc824879@github.com>
Message-ID: <N_S-qenwQRrnf6SrBQb3E1KeYyKJDoST07mW7XohiLk=.0ebf5015-1f3c-4eb5-aba9-df8319a60f5e@github.com>

On Wed, 10 Dec 2025 16:59:06 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit [c9ab330b](https://github.com/openjdk/jdk/commit/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Xiaolong Peng on 9 Dec 2025 and was reviewed by William Kemper and Kelvin Nilsen.
> 
> It is a necessary bug fix to address the crash caused by recently change to arraycopy barrier. 
> 
> Thanks!

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28751#pullrequestreview-3563623666

From wkemper at openjdk.org  Wed Dec 10 17:37:16 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 10 Dec 2025 17:37:16 GMT
Subject: [jdk26] RFR: 8373116: Genshen: arraycopy_work should be always
 done for arrays in old gen during young concurrent marking
In-Reply-To: <fm5g78BYrCWtkUxsPrmpai8prFmEM-L9B3xPrxNwgZk=.f0bd81e2-eb83-47dc-9bc4-34f9fc824879@github.com>
References: <fm5g78BYrCWtkUxsPrmpai8prFmEM-L9B3xPrxNwgZk=.f0bd81e2-eb83-47dc-9bc4-34f9fc824879@github.com>
Message-ID: <QfBtlNDyHNGsZ7b_-LqEVPVqVYTcvCSupJNFUQm0bZw=.6cccc55e-2bec-4c52-af6c-1f05a195ae02@github.com>

On Wed, 10 Dec 2025 16:59:06 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit [c9ab330b](https://github.com/openjdk/jdk/commit/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Xiaolong Peng on 9 Dec 2025 and was reviewed by William Kemper and Kelvin Nilsen.
> 
> It is a necessary bug fix to address the crash caused by recently change to arraycopy barrier. 
> 
> Thanks!

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28751#pullrequestreview-3563722464

From xpeng at openjdk.org  Wed Dec 10 17:37:17 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 10 Dec 2025 17:37:17 GMT
Subject: [jdk26] RFR: 8373116: Genshen: arraycopy_work should be always
 done for arrays in old gen during young concurrent marking
In-Reply-To: <fm5g78BYrCWtkUxsPrmpai8prFmEM-L9B3xPrxNwgZk=.f0bd81e2-eb83-47dc-9bc4-34f9fc824879@github.com>
References: <fm5g78BYrCWtkUxsPrmpai8prFmEM-L9B3xPrxNwgZk=.f0bd81e2-eb83-47dc-9bc4-34f9fc824879@github.com>
Message-ID: <YLd2Ip8Yk4eeDf7loT_Ylv8oabYblr_v3EA5sYZEtiU=.82463b11-6621-4414-9aa0-769440804ae4@github.com>

On Wed, 10 Dec 2025 16:59:06 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit [c9ab330b](https://github.com/openjdk/jdk/commit/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Xiaolong Peng on 9 Dec 2025 and was reviewed by William Kemper and Kelvin Nilsen.
> 
> It is a necessary bug fix to address the crash caused by recently change to arraycopy barrier. 
> 
> Thanks!

Thank you all!

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

PR Comment: https://git.openjdk.org/jdk/pull/28751#issuecomment-3638204799

From xpeng at openjdk.org  Wed Dec 10 17:37:17 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 10 Dec 2025 17:37:17 GMT
Subject: [jdk26] Integrated: 8373116: Genshen: arraycopy_work should be always
 done for arrays in old gen during young concurrent marking
In-Reply-To: <fm5g78BYrCWtkUxsPrmpai8prFmEM-L9B3xPrxNwgZk=.f0bd81e2-eb83-47dc-9bc4-34f9fc824879@github.com>
References: <fm5g78BYrCWtkUxsPrmpai8prFmEM-L9B3xPrxNwgZk=.f0bd81e2-eb83-47dc-9bc4-34f9fc824879@github.com>
Message-ID: <3ZHDolYBNGlDXNjr2Eo1DUWTLTsFUh-zndK53Bu75wg=.1e9ceb99-7347-4fc9-8a99-bf18f1a4c70c@github.com>

On Wed, 10 Dec 2025 16:59:06 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit [c9ab330b](https://github.com/openjdk/jdk/commit/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Xiaolong Peng on 9 Dec 2025 and was reviewed by William Kemper and Kelvin Nilsen.
> 
> It is a necessary bug fix to address the crash caused by recently change to arraycopy barrier. 
> 
> Thanks!

This pull request has now been integrated.

Changeset: 15b5789f
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15b5789f554cb7b2467a6a0efb4e4cd129ee609b
Stats:     10 lines in 2 files changed: 5 ins; 0 del; 5 mod

8373116: Genshen: arraycopy_work should be always done for arrays in old gen during young concurrent marking
8372498: [genshen] gc/TestAllocHumongousFragment.java#generational causes intermittent SIGSEGV crashes

Reviewed-by: shade, wkemper
Backport-of: c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3

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

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

From btaylor at openjdk.org  Wed Dec 10 19:24:15 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Wed, 10 Dec 2025 19:24:15 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue
Message-ID: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>

This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.

There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 

This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.

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

Commit messages:
 - Additional jcheck whitespace fix
 - Fix missing includes and whitespace in previous commit
 - 8372250: Merge PtrQueue into SATBMarkQueue

Changes: https://git.openjdk.org/jdk/pull/28755/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28755&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372250
  Stats: 474 lines in 6 files changed: 173 ins; 287 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/28755.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28755/head:pull/28755

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

From manc at openjdk.org  Wed Dec 10 20:40:45 2025
From: manc at openjdk.org (Man Cao)
Date: Wed, 10 Dec 2025 20:40:45 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize [v2]
In-Reply-To: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
Message-ID: <IczDspgKhNABI6G2KpPThzR1W0CdS9EZZe6PfO2s4KE=.18fee794-f92f-446d-9faa-d2a30b2326f8@github.com>

> Hi all,
> 
> Could anyone review this test-only improvement to make TestG1ClassUnloadingHWM.java more robust in various configurations?
> See https://bugs.openjdk.org/browse/JDK-8373403 for more details.
> 
> -Man

Man Cao has updated the pull request incrementally with one additional commit since the last revision:

  Switch to check for 'Metadata GC Threshold' for full GCs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28738/files
  - new: https://git.openjdk.org/jdk/pull/28738/files/05605e16..6c6fbfe9

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

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

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

From manc at openjdk.org  Wed Dec 10 20:43:50 2025
From: manc at openjdk.org (Man Cao)
Date: Wed, 10 Dec 2025 20:43:50 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize
In-Reply-To: <fTtyydCO4BkW6fp19IVDVEdgAdZkSb1w-c-eojTdAok=.800ee172-54e1-4ae6-b6cf-f6df150bfeb1@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
 <fTtyydCO4BkW6fp19IVDVEdgAdZkSb1w-c-eojTdAok=.800ee172-54e1-4ae6-b6cf-f6df150bfeb1@github.com>
Message-ID: <rtuuXeWctRaTkVb4J1K-hEiW8c3gdCXqY5iJ0Zyz6-g=.bedcea00-fa46-4321-9556-cd9160795d4e@github.com>

On Wed, 10 Dec 2025 13:51:55 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I think this is a test bug: it should check whether the Metadata GCs is a full gc and not a young gc starting a concurrent mark. Right now the test just checks whether there is any full gc and not a concurrent start gc at all. The regexp should add a ?`Metadata GC Threshold` part there.

Updated test to check `Metadata GC Threshold` explicitly, and removed the check for concurrent mark in `testWithoutG1ClassUnloading()`.

Also filed https://bugs.openjdk.org/browse/JDK-8373461 for avoiding the unnecessary concurrent mark.

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

PR Comment: https://git.openjdk.org/jdk/pull/28738#issuecomment-3638882880

From kdnilsen at openjdk.org  Wed Dec 10 21:29:57 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 10 Dec 2025 21:29:57 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v3]
In-Reply-To: <IHILqGB01k3U2I87JkJZRT9UKpJ4E8PHKFPptZG5Nnw=.b9008484-d6b3-4a93-9e61-fec995aa0eb6@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <9gzZlrEzwroH2F-yEC6uzYIPsoKEcTBs_6UZDNFvvCg=.e0e0697f-e537-41fb-9f7f-740acbab4ad1@github.com>
 <IHILqGB01k3U2I87JkJZRT9UKpJ4E8PHKFPptZG5Nnw=.b9008484-d6b3-4a93-9e61-fec995aa0eb6@github.com>
Message-ID: <EwlKMa9Yc1-f1I1feA6oVXGCzpxdghwo3J3yEQD7xTI=.1f08a7f2-d6a6-4df9-ae8f-91177fcd4b2f@github.com>

On Tue, 9 Dec 2025 22:53:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Kelvin Nilsen 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 12 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers-gh
>>  - Add comment to describe behavior of adjust_old_garbage_threshold()
>>  - Simplify representation of growth percentages
>>  - Change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>>  - make old evac ratio adaptive
>>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>>  - change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>>  - Adjust test for new defaults
>>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b2386fa4...c7c22974
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 249:
> 
>> 247:     _live_bytes_after_last_mark + (_live_bytes_after_last_mark * _growth_percent_before_compaction) / 100;
>> 248:   size_t threshold_by_growth_into_percent_remaining = (size_t)
>> 249:     (_live_bytes_after_last_mark + ((ShenandoahHeap::heap()->soft_max_capacity() - _live_bytes_after_last_mark)
> 
> I need to protect against underflow here.  It might be that _live_bytes_after_last_mark is greater than soft_max_capacity().

Done and tested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608266583

From wkemper at openjdk.org  Wed Dec 10 21:35:14 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 10 Dec 2025 21:35:14 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v4]
In-Reply-To: <XNApCPWM-nokDk9gu6pQBuQoPGZrDMT09MyyeLqcGqo=.76e5d732-60b2-4dc0-82a0-ba8554d456a9@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <XNApCPWM-nokDk9gu6pQBuQoPGZrDMT09MyyeLqcGqo=.76e5d732-60b2-4dc0-82a0-ba8554d456a9@github.com>
Message-ID: <Em1knzYBH0HEvDDTA9NXR15dRsBILEGAScG43xU3q-Y=.502ede0d-fddc-4101-bd75-f847f40608ef@github.com>

On Tue, 9 Dec 2025 23:21:39 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
>> 
>> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Protect against underflow when computing old growth trigger threshold

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 290:

> 288:   State _state;
> 289: 
> 290:   static const size_t FRACTIONAL_DENOMINATOR = 65536;

Is anything still using this constant?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608285011

From kbarrett at openjdk.org  Wed Dec 10 21:45:33 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Dec 2025 21:45:33 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue
In-Reply-To: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
Message-ID: <4XzH5yxvb4dk3CiQHac6mn92mqPvvbAxHmMKHTcmffg=.2a49be11-719d-4333-85ba-60260fa5fb12@github.com>

On Wed, 10 Dec 2025 18:26:16 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
> 
> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
> 
> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.

This looks mostly good, with just a few minor nits.

I think there may be further simplifications and cleanups possible, but
looking for those can be done later, once this relatively clean merging change
is done.

[appropriate place is not commentable in github diff]
SATBMarkQueueSet::enqueue_completed_buffer should no longer be virtual.  (This
would have been caught if it had been changed to "override" once that was
permitted, but nobody got around to that.)

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

> 48: 
> 49: SATBMarkQueue::~SATBMarkQueue() {
> 50:     assert(_buf == nullptr, "queue must be flushed before delete");

Too much indentation.

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

> 426: void SATBMarkQueueSet::deallocate_buffer(BufferNode* node) {
> 427:   _allocator->release(node);
> 428: }

Missing newline?

src/hotspot/share/gc/shared/satbMarkQueue.hpp line 196:

> 194:   // Installs a new buffer into queue.
> 195:   void install_new_buffer(SATBMarkQueue& queue);
> 196: 

These helper functions hoisted from PtrQueueSet should be private rather than protected here.

src/hotspot/share/gc/shared/satbMarkQueue.hpp line 249:

> 247: 
> 248:   // A completed buffer is a buffer the mutator is finished with, and
> 249:   // is ready to be processed by the collector.  It need not be full.

This comment (copied from ptrQueueSet) seems misplaced here. Perhaps it should be part of the
class description?

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28755#pullrequestreview-3564478203
PR Review Comment: https://git.openjdk.org/jdk/pull/28755#discussion_r2608208876
PR Review Comment: https://git.openjdk.org/jdk/pull/28755#discussion_r2608213644
PR Review Comment: https://git.openjdk.org/jdk/pull/28755#discussion_r2608282954
PR Review Comment: https://git.openjdk.org/jdk/pull/28755#discussion_r2608246180

From kdnilsen at openjdk.org  Wed Dec 10 21:50:29 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 10 Dec 2025 21:50:29 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
Message-ID: <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>

> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
> 
> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Remove FRACTIONAL_DENOMINATOR constat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28561/files
  - new: https://git.openjdk.org/jdk/pull/28561/files/79a21ee6..41a83389

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

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

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

From kdnilsen at openjdk.org  Wed Dec 10 21:50:31 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 10 Dec 2025 21:50:31 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v4]
In-Reply-To: <Em1knzYBH0HEvDDTA9NXR15dRsBILEGAScG43xU3q-Y=.502ede0d-fddc-4101-bd75-f847f40608ef@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <XNApCPWM-nokDk9gu6pQBuQoPGZrDMT09MyyeLqcGqo=.76e5d732-60b2-4dc0-82a0-ba8554d456a9@github.com>
 <Em1knzYBH0HEvDDTA9NXR15dRsBILEGAScG43xU3q-Y=.502ede0d-fddc-4101-bd75-f847f40608ef@github.com>
Message-ID: <I6ZCTl1F8euaRS0cex2wThJS8raZLxAIO4p2TvoV7gc=.6f97bc79-5f3a-49b1-9efe-19953d581f30@github.com>

On Wed, 10 Dec 2025 21:32:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Protect against underflow when computing old growth trigger threshold
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 290:
> 
>> 288:   State _state;
>> 289: 
>> 290:   static const size_t FRACTIONAL_DENOMINATOR = 65536;
> 
> Is anything still using this constant?

Thanks for the catch.  Removed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608316470

From wkemper at openjdk.org  Wed Dec 10 21:55:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 10 Dec 2025 21:55:31 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
Message-ID: <fIpCMpjdmtC6t1lZ0pYiZDe2b9-s9XrJXfcgVs4Mb44=.0179f9d6-78f9-4436-b9eb-4395fd169196@github.com>

On Wed, 10 Dec 2025 21:50:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
>> 
>> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove FRACTIONAL_DENOMINATOR constat

Thank you for the comments and the simplification.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28561#pullrequestreview-3564640549

From xpeng at openjdk.org  Thu Dec 11 00:00:37 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 00:00:37 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <lEz_sMnMND0kngc357XW-6ttuf3d8XpIzFRg3dhku7o=.191a1c01-3b76-4f5a-92d9-d009f700993b@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
 <lEz_sMnMND0kngc357XW-6ttuf3d8XpIzFRg3dhku7o=.191a1c01-3b76-4f5a-92d9-d009f700993b@github.com>
Message-ID: <LUnrzmltzpNYGuTEtdC95Dtx4QIgU8uSQI2qKfTfV7w=.ba567d6b-fa60-4b29-8b68-b6e980829b74@github.com>

On Fri, 5 Dec 2025 18:47:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set requested gc cause under a lock when allocation fails
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp line 145:
> 
>> 143:   // Notifies the control thread, but does not update the requested cause or generation.
>> 144:   // The overloaded variant should be used when the _control_lock is already held.
>> 145:   void notify_cancellation(GCCause::Cause cause);
> 
> These methods were the root cause here. `ShenandoahHeap::_canceled_gc` is read/written atomically, but `ShenandoahGenerationalControlThread::_requested_gc_cause` is read/written under a lock. These `notify_cancellation` methods did _not_ update `_requested_gc_cause` at all. So, in the failure I observed we had:
> 1. Control thread finishes cycle and sees no cancellation is requested (no lock used).
> 2. Mutator thread fails allocation, cancels GC (again, no lock used), and does _not_ change `_requested_gc_cause`.
> 3. Control thread takes `_control_lock` and checks `_requested_gc_cause` and sees  `_no_gc`  (because `notify_cancellation` didn't change it) and `waits` forever now.
> 
> 
> The fix here is to replace `notify_cancellation` with `notify_control_thread` which serializes updates to `_requested_gc_cause` under  `_control_lock`.

I was looking at the places where `ShenandoahHeap::clear_cancelled_gc` is called, I feel the problem is more likely from op_final_update_refs:


void ShenandoahConcurrentGC::op_final_update_refs() {
  ShenandoahHeap* const heap = ShenandoahHeap::heap();
   ... 
  ...
  // Clear cancelled GC, if set. On cancellation path, the block before would handle
  // everything.
  if (heap->cancelled_gc()) {
    heap->clear_cancelled_gc();
  }
  ...
  ...
}


Let's say there is concurrent GC running, right before the final update refs safepoint, there is mutator allocation failure:
1. The mutator tries to cancel the the concurrent GC and notify controller thread.
2. The mutator block itself at `_alloc_failure_waiters_lock`, claiming safepoint safe as well. 
3. concurrent GC enter the final update refs (VM operation)
4. in final update refs, VMThread sees cancelled_gc and clear it.
5. concurrent GC finishes, but cancelled_gc has been cleared so it won't notify the mutator. 

The fix seem to work in generational mode, but may not work in non-generational mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28665#discussion_r2608573677

From xpeng at openjdk.org  Thu Dec 11 00:15:11 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 00:15:11 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <LUnrzmltzpNYGuTEtdC95Dtx4QIgU8uSQI2qKfTfV7w=.ba567d6b-fa60-4b29-8b68-b6e980829b74@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
 <lEz_sMnMND0kngc357XW-6ttuf3d8XpIzFRg3dhku7o=.191a1c01-3b76-4f5a-92d9-d009f700993b@github.com>
 <LUnrzmltzpNYGuTEtdC95Dtx4QIgU8uSQI2qKfTfV7w=.ba567d6b-fa60-4b29-8b68-b6e980829b74@github.com>
Message-ID: <S5pjyYCYlxNSVH_J9KQOxDSC44s-p8Fy1B0mPJw1zVg=.6579ffb2-ba7f-4803-a7cf-2f7efc9a923f@github.com>

On Wed, 10 Dec 2025 23:35:45 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp line 145:
>> 
>>> 143:   // Notifies the control thread, but does not update the requested cause or generation.
>>> 144:   // The overloaded variant should be used when the _control_lock is already held.
>>> 145:   void notify_cancellation(GCCause::Cause cause);
>> 
>> These methods were the root cause here. `ShenandoahHeap::_canceled_gc` is read/written atomically, but `ShenandoahGenerationalControlThread::_requested_gc_cause` is read/written under a lock. These `notify_cancellation` methods did _not_ update `_requested_gc_cause` at all. So, in the failure I observed we had:
>> 1. Control thread finishes cycle and sees no cancellation is requested (no lock used).
>> 2. Mutator thread fails allocation, cancels GC (again, no lock used), and does _not_ change `_requested_gc_cause`.
>> 3. Control thread takes `_control_lock` and checks `_requested_gc_cause` and sees  `_no_gc`  (because `notify_cancellation` didn't change it) and `waits` forever now.
>> 
>> 
>> The fix here is to replace `notify_cancellation` with `notify_control_thread` which serializes updates to `_requested_gc_cause` under  `_control_lock`.
>
> I was looking at the places where `ShenandoahHeap::clear_cancelled_gc` is called, I feel the problem is more likely from op_final_update_refs:
> 
> 
> void ShenandoahConcurrentGC::op_final_update_refs() {
>   ShenandoahHeap* const heap = ShenandoahHeap::heap();
>    ... 
>   ...
>   // Clear cancelled GC, if set. On cancellation path, the block before would handle
>   // everything.
>   if (heap->cancelled_gc()) {
>     heap->clear_cancelled_gc();
>   }
>   ...
>   ...
> }
> 
> 
> Let's say there is concurrent GC running, right before the final update refs safepoint, there is mutator allocation failure:
> 1. The mutator tries to cancel the the concurrent GC and notify controller thread.
> 2. The mutator block itself at `_alloc_failure_waiters_lock`, claiming safepoint safe as well. 
> 3. concurrent GC enter the final update refs (VM operation)
> 4. in final update refs, VMThread sees cancelled_gc and clear it.
> 5. concurrent GC finishes, but cancelled_gc has been cleared so it won't notify the mutator. 
> 
> The fix seems to work in generational mode, but may not work in non-generational mode.

While I was staring at the code ShenandoahController::handle_alloc_failure today, I found there is discrepancy between ShenandoahGenerationalControlThread and  ShenandoahControlThread, I created a [bug](https://bugs.openjdk.org/browse/JDK-8373468) to unify the behavior, we could fix the issue in ShenandoahControlThread there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28665#discussion_r2608651279

From btaylor at openjdk.org  Thu Dec 11 00:36:47 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Thu, 11 Dec 2025 00:36:47 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue [v2]
In-Reply-To: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
Message-ID: <aqTOB-TRkMKMz3nmjxJr-63dB7mL4K7cIn_9ttXlA00=.22157ade-39fb-4e3f-8c6f-43e6aaa0e302@github.com>

> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
> 
> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
> 
> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.

Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:

  Address PR feedback from kimbarrett

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28755/files
  - new: https://git.openjdk.org/jdk/pull/28755/files/bc24bfba..148aa4f8

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

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

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

From ysr at openjdk.org  Thu Dec 11 00:58:31 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 11 Dec 2025 00:58:31 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
Message-ID: <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>

On Wed, 10 Dec 2025 21:50:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
>> 
>> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 35%, of the memory not live in old at the last marking of old.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove FRACTIONAL_DENOMINATOR constat

I left a few cosmetic comments, but I have the feeling that the verbal description of the parameters isn't faithful to the actual implementation.

Moreover, it appeared to me, quite subjectively, that the triggering criteria are sufficiently complex that capturing them accurately as tunables that users could usefully tune is a bit difficult without reference to how the adjustments themselves work.

I think your changes are probably good and yield improvements in performance that you can demonstrate in practice. So I think these changes should go in.

That said, I feel there may be an opportunity to slightly simplify the implementation or at least expose only those tunables that one can expect to be able to adjust easily. As it stands, I find the implementation to be such that most users will likely have a hard time using these tunables in any intelligent way. I'd like us to see if we can somehow convey the tuning aspect more clearly in the description of these parameters (while hopefully not compormising accuracy of the descriptions).

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 105:

> 103:   size_t _fragmentation_last_old_region;
> 104: 
> 105:   // adapted value of ShenandoahOldGarbageThreshold

May be reword to:

// a dynamic threshold of garbage for an old
// region to be deemed eligible for evacuation.

since `ShenandoahOldGarbageThreshold` is a constant parameter to the JVM.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 206:

> 204:   bool is_experimental() override;
> 205: 
> 206: 

Although just an accessor, I'd document this API, perhaps using its intended usage as understood by its client:


// Returns the current value of a dynamically
// adjusted threshold percentage of garbage
// above which an Old region should be deemed
// eligible for evacuation.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 214:

> 212: 
> 213:   // The normal old_garbage_threshold is specified by ShenandoahOldGarbageThreshold command-line argument, with default
> 214:   // value 25, denoting that a region that has at least 25% garbage is eligible for compaction.  With default values for

compaction or evacuation?

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

> 507: 
> 508: // Preselect for inclusion into the collection set regions whose age is at or above tenure age which contain more than
> 509: // the old garbage threshold amount of garbage.  We identify these regions by setting the appropriate entry of

Is amount in this sentence a percentage? If so, I'd say: `We only select regions whose garbage percentage exceeds a dynamically adjusted threshold.`
Using "old garbage threshold amount" by itself can be confusing, since "amount" doesn't sound like a percentage which is what I believe we mean here.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 119:

> 117:     _card_scan(nullptr),
> 118:     _state(WAITING_FOR_BOOTSTRAP),
> 119:     _growth_percent_before_compaction(INITIAL_PERCENT_GROWTH_BEFORE_COMPACTION)

Use either "percent_growth" or "growth_percent" consistently in both names.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 306:

> 304: 
> 305:   // How much growth in usage before we trigger old collection as a percent of soft_max_capacity
> 306:   size_t _growth_percent_before_compaction;

I'd prefer we didn't use the term "compaction". Would replacing it with "collection", as in the comment, work? Or is there a specific reason you want to say "compaction" here?

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 307:

> 305:   // How much growth in usage before we trigger old collection as a percent of soft_max_capacity
> 306:   size_t _growth_percent_before_compaction;
> 307: 

See comment on naming of percent quantities in .cpp above.

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 65:

> 63:           "(Generational mode only) If the usage within old generation "    \
> 64:           "has grown by at least this percent of its live memory size "     \
> 65:           "at the start of the previous old-generation marking effort, "    \

Did you intend to say "at the _end_ of the previous old-generation marking effort" above?

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 71:

> 69:   product(double, ShenandoahMinOldGenGrowthRemainingHeapPercent,            \
> 70:           35, EXPERIMENTAL,                                                 \
> 71:           "(Generational mode only) If the usage within old generation "    \

I find this comment very confusing, and not amenable to use as a tuning device. Can thus be converted into a knob that is history-independent/memory-less -- i.e. solely state-dependent?

Otherwise, let's try and word this so that it's simpler to parse. This could include a multiple sentence description.

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 90:

> 88:           "ShenandoahGenerationalDoNotIgnoreGrowthAfterYoungCycles "        \
> 89:           "consecutive cycles have been completed following the "           \
> 90:           "preceding old-gen collection.")                                  \

Here again, like my remark below, we can effectively decouple the two options and simplify the verbage by merely saying:


// Do not use Old generation growth as a triggering criterion
// when usage is lower than this percentage of heap.


I am not sure if "of heap" is correct, or if there is some other implicit percentage of the old generation capacity that one has in mind here.

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 96:

> 94:           100, EXPERIMENTAL,                                                \
> 95:           "(Generational mode only) Even if the usage of old generation "   \
> 96:           "is below ShenandoahIgnoreOldGrowthBelowPercentage, "             \

The reference to `ShenandoahIgnoreOldGrowthBelowPercentage` (SIOGBP) seems to me to be spurious and confusing. I think this might be a simpler phrasing, without any reference to SIOGBP:


\\ Trigger an Old collection if Old generation usage has grown,
\\ and this many Young collections have happened,
\\ since the last Old collection.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28561#pullrequestreview-3564758554
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608434949
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608566349
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608443529
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608509748
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608643499
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608604393
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608648317
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608454990
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608498445
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608491539
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608477270

From ysr at openjdk.org  Thu Dec 11 00:58:32 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 11 Dec 2025 00:58:32 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
Message-ID: <mKn330cwE09Jyy3Z-RMPNPctRt-Ow8AwNG27EUCsc9s=.beb8b662-842e-41fb-a16f-164454c62bd7@github.com>

On Wed, 10 Dec 2025 22:28:01 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FRACTIONAL_DENOMINATOR constat
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 105:
> 
>> 103:   size_t _fragmentation_last_old_region;
>> 104: 
>> 105:   // adapted value of ShenandoahOldGarbageThreshold
> 
> May be reword to:
> 
> // a dynamic threshold of garbage for an old
> // region to be deemed eligible for evacuation.
> 
> since `ShenandoahOldGarbageThreshold` is a constant parameter to the JVM.

As I write this, I realize "Old region" may not be the right term here. It should be "an Old or otherwise tenurable region" because it seems regions that are Young but tenurable are filtered through this check, not just Old regions?

> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 119:
> 
>> 117:     _card_scan(nullptr),
>> 118:     _state(WAITING_FOR_BOOTSTRAP),
>> 119:     _growth_percent_before_compaction(INITIAL_PERCENT_GROWTH_BEFORE_COMPACTION)
> 
> Use either "percent_growth" or "growth_percent" consistently in both names.

And make those two consistent with either "percent_live" or "live_percent" below.

(These comments from me actually belong in the .hpp where these are defined.)

> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 71:
> 
>> 69:   product(double, ShenandoahMinOldGenGrowthRemainingHeapPercent,            \
>> 70:           35, EXPERIMENTAL,                                                 \
>> 71:           "(Generational mode only) If the usage within old generation "    \
> 
> I find this comment very confusing, and not amenable to use as a tuning device. Can thus be converted into a knob that is history-independent/memory-less -- i.e. solely state-dependent?
> 
> Otherwise, let's try and word this so that it's simpler to parse. This could include a multiple sentence description.

I might even combine the descriptions of the previous and this parameter, which work in tandem, to describe how to tune them. e.g.


Old generation collection is triggered by determining when its usage has grown past a threshold since the end of the last Old generation collection, viz.
1. if the usage exceeds the amount considered live at the last old marking cycle plus ShenandoahMinOldGenGrowthPercent markup, or
2. if the current remaining headroom falls below ShenandoahMinOldGenGrowthRemainingHeapPercent of the complement of what was considered live at the last old marking cycle.


I am not sure if the verbage in (2) above is correct.

> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 90:
> 
>> 88:           "ShenandoahGenerationalDoNotIgnoreGrowthAfterYoungCycles "        \
>> 89:           "consecutive cycles have been completed following the "           \
>> 90:           "preceding old-gen collection.")                                  \
> 
> Here again, like my remark below, we can effectively decouple the two options and simplify the verbage by merely saying:
> 
> 
> // Do not use Old generation growth as a triggering criterion
> // when usage is lower than this percentage of heap.
> 
> 
> I am not sure if "of heap" is correct, or if there is some other implicit percentage of the old generation capacity that one has in mind here.

As I read the code for the old heuristic growth trigger, I realize my rewording above is incorrect.

I think the code in the triggering could be simplified a bit to allow a more crisp description of these parameters.

Let me talk with you offline (face to face).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608586522
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608646531
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608735072
PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608743619

From ysr at openjdk.org  Thu Dec 11 00:58:34 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 11 Dec 2025 00:58:34 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <mKn330cwE09Jyy3Z-RMPNPctRt-Ow8AwNG27EUCsc9s=.beb8b662-842e-41fb-a16f-164454c62bd7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
 <mKn330cwE09Jyy3Z-RMPNPctRt-Ow8AwNG27EUCsc9s=.beb8b662-842e-41fb-a16f-164454c62bd7@github.com>
Message-ID: <-Ma5FOOlP7qtDmaJtpnglct3_plcnFLYnVnUwWdLpTA=.c154aed7-fc00-4011-8d96-8652cc996234@github.com>

On Thu, 11 Dec 2025 00:09:12 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 119:
>> 
>>> 117:     _card_scan(nullptr),
>>> 118:     _state(WAITING_FOR_BOOTSTRAP),
>>> 119:     _growth_percent_before_compaction(INITIAL_PERCENT_GROWTH_BEFORE_COMPACTION)
>> 
>> Use either "percent_growth" or "growth_percent" consistently in both names.
>
> And make those two consistent with either "percent_live" or "live_percent" below.
> 
> (These comments from me actually belong in the .hpp where these are defined.)

I think "percent" at the end makes sense, so "live_percent" and "growth_percent", so only the "initial growth percent" name needs to be adjusted for consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2608654130

From kbarrett at openjdk.org  Thu Dec 11 01:09:26 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 11 Dec 2025 01:09:26 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue [v2]
In-Reply-To: <aqTOB-TRkMKMz3nmjxJr-63dB7mL4K7cIn_9ttXlA00=.22157ade-39fb-4e3f-8c6f-43e6aaa0e302@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
 <aqTOB-TRkMKMz3nmjxJr-63dB7mL4K7cIn_9ttXlA00=.22157ade-39fb-4e3f-8c6f-43e6aaa0e302@github.com>
Message-ID: <UtTQr2WDrZMXFpsbBSiFw6XF0Zhnkkq8OwGVPy7rj48=.a57cc0e2-d827-4e33-bbd6-40285a5e53d5@github.com>

On Thu, 11 Dec 2025 00:36:47 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
>> 
>> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
>> 
>> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feedback from kimbarrett

commit 148aa4f didn't address this comment:
> [appropriate place is not commentable in github diff]
> SATBMarkQueueSet::enqueue_completed_buffer should no longer be virtual. (This
> would have been caught if it had been changed to "override" once that was
> permitted, but nobody got around to that.)

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

PR Comment: https://git.openjdk.org/jdk/pull/28755#issuecomment-3639591608

From jsikstro at openjdk.org  Thu Dec 11 07:57:26 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Dec 2025 07:57:26 GMT
Subject: RFR: 8373421: Parallel: Rename young generation eden and survivor
 space pool
In-Reply-To: <MO1KogXIlCHwgeKjpjFe5cQhM6d9x2SBbKvFIXIZXlU=.698b10a2-7987-435a-9d8d-a35b74c5bfd5@github.com>
References: <MO1KogXIlCHwgeKjpjFe5cQhM6d9x2SBbKvFIXIZXlU=.698b10a2-7987-435a-9d8d-a35b74c5bfd5@github.com>
Message-ID: <nJ1FptzBD92joeYN8RtKHTTLDTNv-KEQmabcz5R2oJg=.23ec5009-d078-4a1a-8db0-3362a7ddab6c@github.com>

On Wed, 10 Dec 2025 13:11:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial renaming two `*SpacePool` classes:
> 
> 
> EdenMutableSpacePool -> PSEdenSpacePool
> SurvivorMutableSpacePool -> PSSurvivorSpacePool
> 
> Test: tier1

Looks good.

A side note, I can see that Serial is the only GC that calls its file "serialMemoryPools.hpp", while all other GCs call it "..MemoryPool.hpp".

$ find src/hotspot/share/gc -name "*MemoryPool*.hpp"
src/hotspot/share/gc/epsilon/epsilonMemoryPool.hpp
src/hotspot/share/gc/g1/g1MemoryPool.hpp
src/hotspot/share/gc/parallel/psMemoryPool.hpp
src/hotspot/share/gc/serial/serialMemoryPools.hpp
src/hotspot/share/gc/shenandoah/shenandoahMemoryPool.hpp

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28744#pullrequestreview-3566170774

From xpeng at openjdk.org  Thu Dec 11 08:06:21 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 08:06:21 GMT
Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock after
 allocation failure even block parameter is false
Message-ID: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>

There is behavior discrepancy between Shenandoah generational mode and non-generational when it handles mutator allocation failure, as stated in the description of [JDK-8373468](https://bugs.openjdk.org/browse/JDK-8373468), in non-generational, the `block` parameter may not always work.

Further looking into ShenandoahGenerationalControlThread and ShenandoahControlThread, they handle the _requested_gc_cause and ShenandoahHeap::cancelled_cause differently in other places as well, the change in this PR will minimize the gap to unify the behavior, and also fix potentially missed allocation failure notifications in some rare cases for both control threads.

### Test
- [x] hotspot_gc_shenandoah
- [ ] GHA (includes tier1 but no unit unit with gtest)
- [x] gtest

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

Commit messages:
 - Need to clear _gc_requested and _requested_gc_cause after checking
 - Align behaviour for non-generational mode
 - Fix
 - Add missing header file runtime/atomic.hpp
 - Use Atomic to store _requested_gc_cause to ensure atomicity
 - alloc_failure_pending set to true if _requested_gc_cause is alloc failure
 - Fix a build error
 - Shenandoah: Mutator may block at _gc_waiters_lock after allocation failure even block parameter is false

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

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

From rmarchenko at openjdk.org  Thu Dec 11 08:51:36 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 11 Dec 2025 08:51:36 GMT
Subject: Integrated: 8372860: TestCodeCacheUnloadDuringConcCycle fails on ARM32
In-Reply-To: <jOhw4WTUFb4J1NVe0sRvSE0PRcCh67-ZUPmSS5c8ACo=.d22e03cd-b293-441c-b99c-7c12dbc6acf8@github.com>
References: <jOhw4WTUFb4J1NVe0sRvSE0PRcCh67-ZUPmSS5c8ACo=.d22e03cd-b293-441c-b99c-7c12dbc6acf8@github.com>
Message-ID: <MsNZxnXsYceI0nYbn23-4yUxPJdePDqZIhRd7DZLdTI=.68e9ed20-fc8a-4354-9fff-a725180865c1@github.com>

On Wed, 10 Dec 2025 10:54:33 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> Increasing number of iterations in the test, to give it a chance to fill CodeCache enough to reach the required threshold to trigger CodeCache GC on Linux-aarch32.
> 
> The time of the test is increased, but it seems still reasonable. (15s --> 35s on my laptop, linux64)
> 
> I confirm that this fix makes the test passed on linux-aarch32.

This pull request has now been integrated.

Changeset: 6a6ff876
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a6ff876c515eba6cc89320e02dc5739d4540316
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8372860: TestCodeCacheUnloadDuringConcCycle fails on ARM32

Reviewed-by: tschatzl, shade

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

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

From tschatzl at openjdk.org  Thu Dec 11 08:52:25 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 11 Dec 2025 08:52:25 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize
In-Reply-To: <rtuuXeWctRaTkVb4J1K-hEiW8c3gdCXqY5iJ0Zyz6-g=.bedcea00-fa46-4321-9556-cd9160795d4e@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
 <fTtyydCO4BkW6fp19IVDVEdgAdZkSb1w-c-eojTdAok=.800ee172-54e1-4ae6-b6cf-f6df150bfeb1@github.com>
 <rtuuXeWctRaTkVb4J1K-hEiW8c3gdCXqY5iJ0Zyz6-g=.bedcea00-fa46-4321-9556-cd9160795d4e@github.com>
Message-ID: <DjANzrnYezqRub2QjIFCvxHKkX6uyieGKz-isl_djrQ=.5a248fdf-e7f8-4577-afe9-a298c611d484@github.com>

On Wed, 10 Dec 2025 20:41:18 GMT, Man Cao <manc at openjdk.org> wrote:

>Updated test to check Metadata GC Threshold explicitly, and removed the check for concurrent mark in testWithoutG1ClassUnloading().

One can check whether the concurrent start GC has the "Metadata GC Threshold" cause as well in the regexes. Young GC both have the cause (e.g. that "Metadata GC Threshold") as well as a type ("Concurrent Start").

>
>Also filed https://bugs.openjdk.org/browse/JDK-8373461 for avoiding the unnecessary concurrent mark.

Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/28738#issuecomment-3640873533

From manc at openjdk.org  Thu Dec 11 09:26:32 2025
From: manc at openjdk.org (Man Cao)
Date: Thu, 11 Dec 2025 09:26:32 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize [v3]
In-Reply-To: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
Message-ID: <rdCWi1G7JmoFyUphH7XAfXyADYZznRT1yYJe8m_f8So=.e17c9873-c848-44fe-899f-aae266bba343@github.com>

> Hi all,
> 
> Could anyone review this test-only improvement to make TestG1ClassUnloadingHWM.java more robust in various configurations?
> See https://bugs.openjdk.org/browse/JDK-8373403 for more details.
> 
> -Man

Man Cao has updated the pull request incrementally with one additional commit since the last revision:

  Also check for 'Metadata GC Threshold' for young GC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28738/files
  - new: https://git.openjdk.org/jdk/pull/28738/files/6c6fbfe9..70e88efa

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

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

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

From manc at openjdk.org  Thu Dec 11 09:26:32 2025
From: manc at openjdk.org (Man Cao)
Date: Thu, 11 Dec 2025 09:26:32 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize
In-Reply-To: <DjANzrnYezqRub2QjIFCvxHKkX6uyieGKz-isl_djrQ=.5a248fdf-e7f8-4577-afe9-a298c611d484@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
 <fTtyydCO4BkW6fp19IVDVEdgAdZkSb1w-c-eojTdAok=.800ee172-54e1-4ae6-b6cf-f6df150bfeb1@github.com>
 <rtuuXeWctRaTkVb4J1K-hEiW8c3gdCXqY5iJ0Zyz6-g=.bedcea00-fa46-4321-9556-cd9160795d4e@github.com>
 <DjANzrnYezqRub2QjIFCvxHKkX6uyieGKz-isl_djrQ=.5a248fdf-e7f8-4577-afe9-a298c611d484@github.com>
Message-ID: <pkcAlaVSF-VFohpIqvSKI85GHpr3uCkgH6csQsaB2sM=.d1691502-68d9-44e7-90e0-f83c98313e35@github.com>

On Thu, 11 Dec 2025 08:50:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> One can check whether the concurrent start GC has the "Metadata GC Threshold" cause as well in the regexes. Young GC both have the cause (e.g. that "Metadata GC Threshold") as well as a type ("Concurrent Start").

Thanks, done. Now we can keep the check in `testWithoutG1ClassUnloading()` for non-existence of `Pause Young (Concurrent Start) (Metadata GC Threshold)`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28738#issuecomment-3641005350

From dholmes at openjdk.org  Thu Dec 11 09:32:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Dec 2025 09:32:57 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <VCpT9lee1wZv0x6I1tDAsZw1v1WwPrhOccmvLagEj28=.cdfb7c67-bbd2-4a51-ae9c-2e2c760cbd1f@github.com>

On Wed, 10 Dec 2025 18:09:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

Looks good. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28754#pullrequestreview-3566523152

From iwalulya at openjdk.org  Thu Dec 11 10:10:34 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 11 Dec 2025 10:10:34 GMT
Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future
 changes
In-Reply-To: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com>
References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com>
Message-ID: <QIyU8DMUCwQmAhfggjvbiAUYhvUedgZlm0sixWFPTCo=.7a3be58e-239c-4c7c-a061-a9c5c3956675@github.com>

On Tue, 9 Dec 2025 13:39:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This PR slightly changes when we may `InjectGCWorkerCreationFailure`.  At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993,  create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads.
> 
> This change should not change the current behaviour. But help future improvements.
> 
> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge.

Nit:

src/hotspot/share/gc/shared/workerThread.cpp line 118:

> 116: 
> 117:   if (_created_workers > 0 && InjectGCWorkerCreationFailure) {
> 118:     assert(is_init_completed(), "Would be interesting to see if this ever happens");

the assert comment seems vague, probably clearer with just "Initialization not completed"

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28719#pullrequestreview-3566674336
PR Review Comment: https://git.openjdk.org/jdk/pull/28719#discussion_r2609974029

From ayang at openjdk.org  Thu Dec 11 10:59:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 11 Dec 2025 10:59:37 GMT
Subject: RFR: 8373421: Parallel: Rename young generation eden and survivor
 space pool
In-Reply-To: <MO1KogXIlCHwgeKjpjFe5cQhM6d9x2SBbKvFIXIZXlU=.698b10a2-7987-435a-9d8d-a35b74c5bfd5@github.com>
References: <MO1KogXIlCHwgeKjpjFe5cQhM6d9x2SBbKvFIXIZXlU=.698b10a2-7987-435a-9d8d-a35b74c5bfd5@github.com>
Message-ID: <uUR5ziVTrG7Pyuy8Gr38FD7jhKWJQJH7rHa9FtAtYNo=.168d9084-236d-4ec4-a408-07215ed854ab@github.com>

On Wed, 10 Dec 2025 13:11:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial renaming two `*SpacePool` classes:
> 
> 
> EdenMutableSpacePool -> PSEdenSpacePool
> SurvivorMutableSpacePool -> PSSurvivorSpacePool
> 
> Test: tier1

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28744#issuecomment-3641360762

From ayang at openjdk.org  Thu Dec 11 10:59:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 11 Dec 2025 10:59:38 GMT
Subject: Integrated: 8373421: Parallel: Rename young generation eden and
 survivor space pool
In-Reply-To: <MO1KogXIlCHwgeKjpjFe5cQhM6d9x2SBbKvFIXIZXlU=.698b10a2-7987-435a-9d8d-a35b74c5bfd5@github.com>
References: <MO1KogXIlCHwgeKjpjFe5cQhM6d9x2SBbKvFIXIZXlU=.698b10a2-7987-435a-9d8d-a35b74c5bfd5@github.com>
Message-ID: <Pf8WHpdQh3SkXrI0J6b3OgUhl7LdQlKmZIauOPHVQO8=.b3d99f78-1492-4061-bd20-d995950c8869@github.com>

On Wed, 10 Dec 2025 13:11:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial renaming two `*SpacePool` classes:
> 
> 
> EdenMutableSpacePool -> PSEdenSpacePool
> SurvivorMutableSpacePool -> PSSurvivorSpacePool
> 
> Test: tier1

This pull request has now been integrated.

Changeset: aa986be7
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa986be7529b7a2950202dbe6885e5224d331078
Stats:     28 lines in 3 files changed: 0 ins; 0 del; 28 mod

8373421: Parallel: Rename young generation eden and survivor space pool

Reviewed-by: tschatzl, jsikstro

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

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

From stefank at openjdk.org  Thu Dec 11 11:03:25 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 11 Dec 2025 11:03:25 GMT
Subject: RFR: 8373253: Re-work InjectGCWorkerCreationFailure for future
 changes
In-Reply-To: <QIyU8DMUCwQmAhfggjvbiAUYhvUedgZlm0sixWFPTCo=.7a3be58e-239c-4c7c-a061-a9c5c3956675@github.com>
References: <78ejbDKfHkTR88XnHC2t975-zof6vMjdM_M_rTyB0pk=.d5c9798a-b1ca-4299-af35-2caaad2f8106@github.com>
 <QIyU8DMUCwQmAhfggjvbiAUYhvUedgZlm0sixWFPTCo=.7a3be58e-239c-4c7c-a061-a9c5c3956675@github.com>
Message-ID: <sdiIFTH4UzMOM7jM1ACM6cF4FJxlscIxSnUFdDufmYE=.e2d72fb5-f2c2-4fbe-8868-84bb101bc6c8@github.com>

On Thu, 11 Dec 2025 10:07:35 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> This PR slightly changes when we may `InjectGCWorkerCreationFailure`.  At the moment we wait until `is_init_completed()`. I am changing this to instead be after `_created_workers > 0`. The reason is that we might in the future, https://bugs.openjdk.org/browse/JDK-8367993,  create even more threads "on demand", and if so, we would fail VM creation if we inject worker creation failures after the VM is initiated but before we have created any of the worker threads.
>> 
>> This change should not change the current behaviour. But help future improvements.
>> 
>> I have tested this on `test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithG1.java`, the only place where this flag is tested to my knowledge.
>
> src/hotspot/share/gc/shared/workerThread.cpp line 118:
> 
>> 116: 
>> 117:   if (_created_workers > 0 && InjectGCWorkerCreationFailure) {
>> 118:     assert(is_init_completed(), "Would be interesting to see if this ever happens");
> 
> the assert comment seems vague, probably clearer with just "Initialization not completed"

I agree. This sentence is left-overs from my earlier prototype.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28719#discussion_r2610140210

From eastigeevich at openjdk.org  Thu Dec 11 11:24:20 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 11 Dec 2025 11:24:20 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v16]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <tTLfgklJegiPyVkoc01nt4exW548_ExAy0WXLiCfvXg=.443a4b83-78dc-444b-87e1-f4c750e5798b@github.com>

> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>  
> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
> - Disable coherent icache.
> - Trap IC IVAU instructions.
> - Execute:
>    - `tlbi vae3is, xzr`
>    - `dsb sy`
>  
>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>  
> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
> 
> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
> 
> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
> 
> Changes include:
> 
> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
> 
> Testing results: linux fastdebug build
> - Neoverse-N1 (Graviton 2)
>    - [x] tier1: passed
>    - [x] tier2: passed
>    - [x] tier3: passed
>    - [ ] tier4
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2), 5 000 nmethods...

Evgeny Astigeevich has updated the pull request incrementally with two additional commits since the last revision:

 - Add cache DIC IDC status to VM_Version
 - Fix tier3 failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/85691beb..44f43e4e

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

  Stats: 115 lines in 7 files changed: 49 ins; 50 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28328.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328

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

From eastigeevich at openjdk.org  Thu Dec 11 14:18:28 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 11 Dec 2025 14:18:28 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v17]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <R45RCms_eyEpAZycKaEMglj0t9HzZfycDse6luApdJc=.da2bae3f-1b3c-4a14-a1cc-70c744bc8478@github.com>

> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>  
> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
> - Disable coherent icache.
> - Trap IC IVAU instructions.
> - Execute:
>    - `tlbi vae3is, xzr`
>    - `dsb sy`
>  
>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>  
> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
> 
> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
> 
> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
> 
> Changes include:
> 
> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
> 
> Testing results: linux fastdebug build
> - Neoverse-N1 (Graviton 2)
>    - [x] tier1: passed
>    - [x] tier2: passed
>    - [x] tier3: passed
>    - [x] tier4: 3 failures
>       - `containers/docker/TestJcmdWithSideCar.java`: JD...

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

  Fix macos and windows aarch64 builds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/44f43e4e..2448b2d7

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

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

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

From mbaesken at openjdk.org  Thu Dec 11 14:20:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Dec 2025 14:20:49 GMT
Subject: RFR: 8371420: Still sporadic failures of
 gc/TestAlwaysPreTouchBehavior.java#<gcname> on Linux after JDK-8359104 [v2]
In-Reply-To: <VpBceliBtPNJyoZht9DOZLrDhvgTsVaAvZkeSdtKDws=.b3eb8bd7-c1d0-4ba8-b7ee-d70bf1ec5412@github.com>
References: <R0y53QsPKcCXAOydrf8DdROUeDvMxivfTFCBBTnR6Eo=.794be77d-c2b0-4aeb-91cb-eca0ca59264a@github.com>
 <-bQqTnNto5bZsLggV61ChqBIgWE1crdtH6MqdYu5BQ8=.9890d66f-7b60-461a-8b42-31b861aeb6be@github.com>
 <VpBceliBtPNJyoZht9DOZLrDhvgTsVaAvZkeSdtKDws=.b3eb8bd7-c1d0-4ba8-b7ee-d70bf1ec5412@github.com>
Message-ID: <2m7QPPx6dNKiS-PIFx7t1RRyP84m3_0MlyBPCvFIKho=.e71311c7-a7cf-408a-9916-b93cc03081d9@github.com>

On Wed, 10 Dec 2025 13:02:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Additionally, there seems a preexisting issue that the else branch of (available > requiredAvailable) should probably also throw SkippedException?

Sorry maybe I miss something - where do you want to see such a SkippedException added ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28735#issuecomment-3642143975

From xpeng at openjdk.org  Thu Dec 11 14:57:27 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 14:57:27 GMT
Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock
 after allocation failure even block parameter is false [v2]
In-Reply-To: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
Message-ID: <8Av2Uamk28eooDf886YczESyuaUniD538Rt5Dv3gMSg=.20c49530-70cb-4f21-8e3f-fd662dfb732b@github.com>

> There is behavior discrepancy between Shenandoah generational mode and non-generational when it handles mutator allocation failure, as stated in the description of [JDK-8373468](https://bugs.openjdk.org/browse/JDK-8373468), in non-generational, the `block` parameter may not always work.
> 
> Further looking into ShenandoahGenerationalControlThread and ShenandoahControlThread, they handle the _requested_gc_cause and ShenandoahHeap::cancelled_cause differently in other places as well, the change in this PR will minimize the gap to unify the behavior, and also fix potentially missed allocation failure notifications in some rare cases for both control threads.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [ ] GHA (includes tier1 but no unit unit with gtest) - Only one test failure caused by header filer order, fixed. 
> - [x] gtest

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Reorder include statements in shenandoahGenerationalControlThread.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28758/files
  - new: https://git.openjdk.org/jdk/pull/28758/files/e60e71da..b3e18e9f

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

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

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

From kdnilsen at openjdk.org  Thu Dec 11 15:49:27 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 15:49:27 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
Message-ID: <p23BJxk6ElN7XaXTM_17Iuee8XlVpYro0e7DJfBrbfw=.23571a4f-41d5-41f4-be9e-2d9853bc46af@github.com>

On Wed, 10 Dec 2025 22:37:58 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FRACTIONAL_DENOMINATOR constat
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 65:
> 
>> 63:           "(Generational mode only) If the usage within old generation "    \
>> 64:           "has grown by at least this percent of its live memory size "     \
>> 65:           "at the start of the previous old-generation marking effort, "    \
> 
> Did you intend to say "at the _end_ of the previous old-generation marking effort" above?

Actually, since we are using SATB protocol for old marking, the live data is measured as of the start of GC.  (We subtract out the allocations (promotions) that happen during concurrent GC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2611104184

From wkemper at openjdk.org  Thu Dec 11 16:05:51 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Dec 2025 16:05:51 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <S5pjyYCYlxNSVH_J9KQOxDSC44s-p8Fy1B0mPJw1zVg=.6579ffb2-ba7f-4803-a7cf-2f7efc9a923f@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
 <lEz_sMnMND0kngc357XW-6ttuf3d8XpIzFRg3dhku7o=.191a1c01-3b76-4f5a-92d9-d009f700993b@github.com>
 <LUnrzmltzpNYGuTEtdC95Dtx4QIgU8uSQI2qKfTfV7w=.ba567d6b-fa60-4b29-8b68-b6e980829b74@github.com>
 <S5pjyYCYlxNSVH_J9KQOxDSC44s-p8Fy1B0mPJw1zVg=.6579ffb2-ba7f-4803-a7cf-2f7efc9a923f@github.com>
Message-ID: <1Ry7ZarguJ0J8-wxU9GbmBxWv6ya78RydVQrsSDxn2Y=.8701f127-1e77-4b31-99e8-0df241c89bd8@github.com>

On Thu, 11 Dec 2025 00:12:35 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> I was looking at the places where `ShenandoahHeap::clear_cancelled_gc` is called, I feel the problem is more likely from op_final_update_refs:
>> 
>> 
>> void ShenandoahConcurrentGC::op_final_update_refs() {
>>   ShenandoahHeap* const heap = ShenandoahHeap::heap();
>>    ... 
>>   ...
>>   // Clear cancelled GC, if set. On cancellation path, the block before would handle
>>   // everything.
>>   if (heap->cancelled_gc()) {
>>     heap->clear_cancelled_gc();
>>   }
>>   ...
>>   ...
>> }
>> 
>> 
>> Let's say there is concurrent GC running, right before the final update refs safepoint, there is mutator allocation failure:
>> 1. The mutator tries to cancel the the concurrent GC and notify controller thread.
>> 2. The mutator block itself at `_alloc_failure_waiters_lock`, claiming safepoint safe as well. 
>> 3. concurrent GC enter the final update refs (VM operation)
>> 4. in final update refs, VMThread sees cancelled_gc and clear it.
>> 5. concurrent GC finishes, but cancelled_gc has been cleared so it won't notify the mutator. 
>> 
>> The fix seems to work in generational mode, but may not work in non-generational mode.
>
> While I was staring at the code ShenandoahController::handle_alloc_failure today, I found there is discrepancy between ShenandoahGenerationalControlThread and  ShenandoahControlThread, I created a [bug](https://bugs.openjdk.org/browse/JDK-8373468) to unify the behavior, we could fix the issue in ShenandoahControlThread there.

The scenario I described wasn't supposition, that is actually what happened in the debugger. The scenario you describe with `op_final_update_refs` would also be fixed by this PR. The `_requested_gc_cause` field should always be accessed under a lock. The code change here fixes an issue where an allocation failure might not set `_requested_gc_cause` at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28665#discussion_r2611167200

From eastigeevich at openjdk.org  Thu Dec 11 16:21:51 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 11 Dec 2025 16:21:51 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v18]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <55OALV7rkAyerTV2RKIdh1J1qgZ1hUbHMtB-ND3DRZM=.b37afa75-d56e-4372-81fd-22bab5c2c533@github.com>

> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>  
> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
> - Disable coherent icache.
> - Trap IC IVAU instructions.
> - Execute:
>    - `tlbi vae3is, xzr`
>    - `dsb sy`
>  
>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>  
> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
> 
> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
> 
> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
> 
> Changes include:
> 
> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
> 
> Testing results: linux fastdebug build
> - Neoverse-N1 (Graviton 2)
>    - [x] tier1: passed
>    - [x] tier2: passed
>    - [x] tier3: passed
>    - [x] tier4: 3 failures
>       - `containers/docker/TestJcmdWithSideCar.java`: JD...

Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'master' into JDK-8370947
 - Fix macos and windows aarch64 builds
 - Add cache DIC IDC status to VM_Version
 - Fix tier3 failures
 - Fix tier1 failures
 - Implement nested ICacheInvalidationContext
 - Fix linux-cross-compile build aarch64
 - Merge branch 'master' into JDK-8370947
 - Remove trailing whitespaces
 - Add support of deferred icache invalidation to other GCs and JIT
 - ... and 15 more: https://git.openjdk.org/jdk/compare/aa986be7...fc4bbe9d

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

Changes: https://git.openjdk.org/jdk/pull/28328/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=17
  Stats: 919 lines in 27 files changed: 852 ins; 21 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/28328.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28328/head:pull/28328

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

From kdnilsen at openjdk.org  Thu Dec 11 16:28:25 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 16:28:25 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <mKn330cwE09Jyy3Z-RMPNPctRt-Ow8AwNG27EUCsc9s=.beb8b662-842e-41fb-a16f-164454c62bd7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
 <mKn330cwE09Jyy3Z-RMPNPctRt-Ow8AwNG27EUCsc9s=.beb8b662-842e-41fb-a16f-164454c62bd7@github.com>
Message-ID: <oHkp4wM05DQhb_1H70hDk9YJNrXIceiDWMJk81MDJrI=.696e6319-93c0-4681-9deb-7be122f83b7d@github.com>

On Wed, 10 Dec 2025 23:43:16 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 105:
>> 
>>> 103:   size_t _fragmentation_last_old_region;
>>> 104: 
>>> 105:   // adapted value of ShenandoahOldGarbageThreshold
>> 
>> May be reword to:
>> 
>> // a dynamic threshold of garbage for an old
>> // region to be deemed eligible for evacuation.
>> 
>> since `ShenandoahOldGarbageThreshold` is a constant parameter to the JVM.
>
> As I write this, I realize "Old region" may not be the right term here. It should be "an Old or otherwise tenurable region" because it seems regions that are Young but tenurable are filtered through this check, not just Old regions?

Thanks for your review and suggestions.  I'll make a pass over this code and try to improve the comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2611248131

From kdnilsen at openjdk.org  Thu Dec 11 16:28:28 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 16:28:28 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
Message-ID: <0KjOEhmxlJ2anomFUqZ0vz1S36zofiteJ2sL1x-KTs0=.2b44157b-6f25-4a04-8cc3-de3ba3e3567b@github.com>

On Wed, 10 Dec 2025 22:32:11 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FRACTIONAL_DENOMINATOR constat
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 214:
> 
>> 212: 
>> 213:   // The normal old_garbage_threshold is specified by ShenandoahOldGarbageThreshold command-line argument, with default
>> 214:   // value 25, denoting that a region that has at least 25% garbage is eligible for compaction.  With default values for
> 
> compaction or evacuation?

Thanks.  Making this change to evacuation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2611252008

From kdnilsen at openjdk.org  Thu Dec 11 16:39:15 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 16:39:15 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <mKn330cwE09Jyy3Z-RMPNPctRt-Ow8AwNG27EUCsc9s=.beb8b662-842e-41fb-a16f-164454c62bd7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
 <mKn330cwE09Jyy3Z-RMPNPctRt-Ow8AwNG27EUCsc9s=.beb8b662-842e-41fb-a16f-164454c62bd7@github.com>
Message-ID: <ZLf4vnGLM4dzzzPhjbo-3BVZNuILseX6EBTsvX3pYIo=.e0227ad6-ab8e-4409-b736-cd432688a76b@github.com>

On Thu, 11 Dec 2025 00:48:58 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 90:
>> 
>>> 88:           "ShenandoahGenerationalDoNotIgnoreGrowthAfterYoungCycles "        \
>>> 89:           "consecutive cycles have been completed following the "           \
>>> 90:           "preceding old-gen collection.")                                  \
>> 
>> Here again, like my remark below, we can effectively decouple the two options and simplify the verbage by merely saying:
>> 
>> 
>> // Do not use Old generation growth as a triggering criterion
>> // when usage is lower than this percentage of heap.
>> 
>> 
>> I am not sure if "of heap" is correct, or if there is some other implicit percentage of the old generation capacity that one has in mind here.
>
> As I read the code for the old heuristic growth trigger, I realize my rewording above is incorrect.
> 
> I think the code in the triggering could be simplified a bit to allow a more crisp description of these parameters.
> 
> Let me talk with you offline (face to face).

Sounds good.  I'm inclined to leave these behaviors as is for now.  These are not the focus of this particular PR.  But let's think about creating a new JBS ticket and PR to improve further if that's ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2611288502

From kdnilsen at openjdk.org  Thu Dec 11 16:39:18 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 16:39:18 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
Message-ID: <EVoHdqxQ2TrBVJZNSGuIuIMVzN51GuEx_9JAJxFtT8M=.2d2e018e-8b49-4dbd-a448-64e0ef794372@github.com>

On Wed, 10 Dec 2025 22:49:18 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FRACTIONAL_DENOMINATOR constat
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 96:
> 
>> 94:           100, EXPERIMENTAL,                                                \
>> 95:           "(Generational mode only) Even if the usage of old generation "   \
>> 96:           "is below ShenandoahIgnoreOldGrowthBelowPercentage, "             \
> 
> The reference to `ShenandoahIgnoreOldGrowthBelowPercentage` (SIOGBP) seems to me to be spurious and confusing. I think this might be a simpler phrasing, without any reference to SIOGBP:
> 
> 
> \\ Trigger an Old collection if Old generation usage has grown,
> \\ and this many Young collections have happened,
> \\ since the last Old collection.

I'll reorder this paragraph to emphasize the triggering.  I don't want to totally remove the mention of ShenandoahIngoreOldGrowthBelowPercentage because the descriptions of these two parameters might otherwise appear to contradict each other.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2611282109

From btaylor at openjdk.org  Thu Dec 11 16:41:24 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Thu, 11 Dec 2025 16:41:24 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue [v3]
In-Reply-To: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
Message-ID: <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>

> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
> 
> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
> 
> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.

Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:

  Remove virtual from SATBMarkQueueSet::enqueue_completed_buffer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28755/files
  - new: https://git.openjdk.org/jdk/pull/28755/files/148aa4f8..517b245f

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

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

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

From kdnilsen at openjdk.org  Thu Dec 11 16:43:39 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 16:43:39 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
Message-ID: <LoOOcWlqpnWdthCQVsFLesGHq_V9JEWgNcOjiL0-H34=.31d44538-ce13-43bd-a1cf-d8f48d2f6f47@github.com>

On Wed, 10 Dec 2025 23:01:38 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FRACTIONAL_DENOMINATOR constat
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 509:
> 
>> 507: 
>> 508: // Preselect for inclusion into the collection set regions whose age is at or above tenure age which contain more than
>> 509: // the old garbage threshold amount of garbage.  We identify these regions by setting the appropriate entry of
> 
> Is amount in this sentence a percentage? If so, I'd say: `We only select regions whose garbage percentage exceeds a dynamically adjusted threshold.`
> Using "old garbage threshold amount" by itself can be confusing, since "amount" doesn't sound like a percentage which is what I believe we mean here.

I've word-smithed your suggestion into the existing paragraph .  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2611304065

From kdnilsen at openjdk.org  Thu Dec 11 16:45:50 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 16:45:50 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
Message-ID: <urSREa09wGUCYFtgPWiE3_yNukUuyPcXHjoyGOPw6c0=.14d20227-3818-4d86-a04f-bdf5d8e1e374@github.com>

On Wed, 10 Dec 2025 23:31:56 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FRACTIONAL_DENOMINATOR constat
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 206:
> 
>> 204:   bool is_experimental() override;
>> 205: 
>> 206: 
> 
> Although just an accessor, I'd document this API, perhaps using its intended usage as understood by its client:
> 
> 
> // Returns the current value of a dynamically
> // adjusted threshold percentage of garbage
> // above which an Old region should be deemed
> // eligible for evacuation.

Thanks.  Inserted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2611312529

From xpeng at openjdk.org  Thu Dec 11 16:54:14 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 16:54:14 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
Message-ID: <58yuhJdcLvchtwbp6Z85z4H6KIr6NyejnkO-CZTG-sk=.9e0ef412-078e-4aef-bd0e-cd141f441f46@github.com>

On Fri, 5 Dec 2025 18:53:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> In some cases, the control thread may fail to observe an allocation failure. This results in the thread which failed to allocate waiting forever for the control thread to run a cycle. Depending on which thread fails to allocate, the process may not make progress.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set requested gc cause under a lock when allocation fails

Thanks for the digging and fixing the issue.

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

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28665#pullrequestreview-3568387538

From xpeng at openjdk.org  Thu Dec 11 16:54:15 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 16:54:15 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <1Ry7ZarguJ0J8-wxU9GbmBxWv6ya78RydVQrsSDxn2Y=.8701f127-1e77-4b31-99e8-0df241c89bd8@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
 <lEz_sMnMND0kngc357XW-6ttuf3d8XpIzFRg3dhku7o=.191a1c01-3b76-4f5a-92d9-d009f700993b@github.com>
 <LUnrzmltzpNYGuTEtdC95Dtx4QIgU8uSQI2qKfTfV7w=.ba567d6b-fa60-4b29-8b68-b6e980829b74@github.com>
 <S5pjyYCYlxNSVH_J9KQOxDSC44s-p8Fy1B0mPJw1zVg=.6579ffb2-ba7f-4803-a7cf-2f7efc9a923f@github.com>
 <1Ry7ZarguJ0J8-wxU9GbmBxWv6ya78RydVQrsSDxn2Y=.8701f127-1e77-4b31-99e8-0df241c89bd8@github.com>
Message-ID: <zXsdN-frp887Bsz0NK05GKqiWTROjQGG8-NPlGloI0U=.2aea630e-6f16-4081-9c44-67ecf26bc1da@github.com>

On Thu, 11 Dec 2025 16:03:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> While I was staring at the code ShenandoahController::handle_alloc_failure today, I found there is discrepancy between ShenandoahGenerationalControlThread and  ShenandoahControlThread, I created a [bug](https://bugs.openjdk.org/browse/JDK-8373468) to unify the behavior, we could fix the issue in ShenandoahControlThread there.
>
> The scenario I described wasn't supposition, that is actually what happened in the debugger. The scenario you describe with `op_final_update_refs` would also be fixed by this PR. The `_requested_gc_cause` field should always be accessed under a lock. The code change here fixes an issue where an allocation failure might not set `_requested_gc_cause` at all.

Yes, I understand the fix will solve the issue for genshen and also fix scenario I described.
I'll solve the potential issue in non-generational Shenandoah in the [PR](https://github.com/openjdk/jdk/pull/28758) to fix the behavior differences in Genshen and non-generational Shenandoah.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28665#discussion_r2611334636

From wkemper at openjdk.org  Thu Dec 11 17:34:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Dec 2025 17:34:22 GMT
Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v5]
In-Reply-To: <Ge-zZoIg1nkufj7LhD6BgeWAryy8BrKd4GcvYDqF_0g=.c2b2cdd5-f722-4e9d-b89f-d6eb192a058f@github.com>
References: <a9W__FkIse8vp8IcikVXQPYrzrqoPoMmtGbBad4U-L0=.6d55276d-15aa-44f7-b2ec-0031d4da77ec@github.com>
 <Ge-zZoIg1nkufj7LhD6BgeWAryy8BrKd4GcvYDqF_0g=.c2b2cdd5-f722-4e9d-b89f-d6eb192a058f@github.com>
Message-ID: <Pwg9jN5oh5FjAsR5H9p90alsKvU4Vnr9_XfHAj2I8J8=.45d90144-3f4c-43ae-924d-4aa34b733abd@github.com>

On Wed, 19 Nov 2025 23:31:41 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Exclude young-young, old-old and honor UseCondCardMark in dirty card marking.
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   hardening of comments
>   
>   remove unintended files

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28204#pullrequestreview-3568545658

From xpeng at openjdk.org  Thu Dec 11 17:38:43 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 17:38:43 GMT
Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock
 after allocation failure even block parameter is false [v3]
In-Reply-To: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
Message-ID: <TZ798QclQN9a2IIK9AkL6abGwWNpCuQIcFMX7eXIFWM=.5e6c0a8d-ab5a-4391-93fa-43fb0d5067ae@github.com>

> There is behavior discrepancy between Shenandoah generational mode and non-generational when it handles mutator allocation failure, as stated in the description of [JDK-8373468](https://bugs.openjdk.org/browse/JDK-8373468), in non-generational, the `block` parameter may not always work.
> 
> Further looking into ShenandoahGenerationalControlThread and ShenandoahControlThread, they handle the _requested_gc_cause and ShenandoahHeap::cancelled_cause differently in other places as well, the change in this PR will minimize the gap to unify the behavior, and also fix potentially missed allocation failure notifications in some rare cases for both control threads.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] GHA (includes tier1 but no unit unit with gtest) 
> - [x] [x] gtest

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Only load _requested_gc_cause once when figuring out pending requests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28758/files
  - new: https://git.openjdk.org/jdk/pull/28758/files/b3e18e9f..467b2746

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

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

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

From wkemper at openjdk.org  Thu Dec 11 17:47:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Dec 2025 17:47:50 GMT
Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock
 after allocation failure even block parameter is false [v3]
In-Reply-To: <TZ798QclQN9a2IIK9AkL6abGwWNpCuQIcFMX7eXIFWM=.5e6c0a8d-ab5a-4391-93fa-43fb0d5067ae@github.com>
References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
 <TZ798QclQN9a2IIK9AkL6abGwWNpCuQIcFMX7eXIFWM=.5e6c0a8d-ab5a-4391-93fa-43fb0d5067ae@github.com>
Message-ID: <QCbEuYmm6IphySyZ7QabRlxcEKsA_c28M87FGSzkmKw=.dcde1073-6844-445c-a299-5617def7b50e@github.com>

On Thu, 11 Dec 2025 17:38:43 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> There is behavior discrepancy between Shenandoah generational mode and non-generational when it handles mutator allocation failure, as stated in the description of [JDK-8373468](https://bugs.openjdk.org/browse/JDK-8373468), in non-generational, the `block` parameter may not always work.
>> 
>> Further looking into ShenandoahGenerationalControlThread and ShenandoahControlThread, they handle the _requested_gc_cause and ShenandoahHeap::cancelled_cause differently in other places as well, the change in this PR will minimize the gap to unify the behavior, and also fix potentially missed allocation failure notifications in some rare cases for both control threads.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] GHA (includes tier1 but no unit unit with gtest) 
>> - [x] [x] gtest
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only load _requested_gc_cause once when figuring out pending requests

Changes requested by wkemper (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp line 46:

> 44: 
> 45:   ShenandoahSharedFlag               _gc_requested;
> 46:   Atomic<GCCause::Cause>             _requested_gc_cause;

`_requested_gc_cause` should always be accessed when holding the `_control_lock`. Making this atomic should not be unnecessary.

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

PR Review: https://git.openjdk.org/jdk/pull/28758#pullrequestreview-3568599040
PR Review Comment: https://git.openjdk.org/jdk/pull/28758#discussion_r2611507205

From xpeng at openjdk.org  Thu Dec 11 18:38:59 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 18:38:59 GMT
Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock
 after allocation failure even block parameter is false [v4]
In-Reply-To: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
Message-ID: <QMur_cHCQfgr1-2_Y6JiKPmaiD2e2TMwL3tO5GXZrq8=.4c67e98b-c6cc-4f63-a1dc-47ca363b6adb@github.com>

> There is behavior discrepancy between Shenandoah generational mode and non-generational when it handles mutator allocation failure, as stated in the description of [JDK-8373468](https://bugs.openjdk.org/browse/JDK-8373468), in non-generational, the `block` parameter may not always work.
> 
> Further looking into ShenandoahGenerationalControlThread and ShenandoahControlThread, they handle the _requested_gc_cause and ShenandoahHeap::cancelled_cause differently in other places as well, the change in this PR will minimize the gap to unify the behavior, and also fix potentially missed allocation failure notifications in some rare cases for both control threads.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] GHA (includes tier1 but no unit unit with gtest) 
> - [x] [x] gtest

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Revert change to use Atomic for _requested_gc_cause

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28758/files
  - new: https://git.openjdk.org/jdk/pull/28758/files/467b2746..469dc1fc

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

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

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

From xpeng at openjdk.org  Thu Dec 11 18:39:01 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 18:39:01 GMT
Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock
 after allocation failure even block parameter is false [v3]
In-Reply-To: <QCbEuYmm6IphySyZ7QabRlxcEKsA_c28M87FGSzkmKw=.dcde1073-6844-445c-a299-5617def7b50e@github.com>
References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
 <TZ798QclQN9a2IIK9AkL6abGwWNpCuQIcFMX7eXIFWM=.5e6c0a8d-ab5a-4391-93fa-43fb0d5067ae@github.com>
 <QCbEuYmm6IphySyZ7QabRlxcEKsA_c28M87FGSzkmKw=.dcde1073-6844-445c-a299-5617def7b50e@github.com>
Message-ID: <vpV2V5-qX0GzMVW4krr4lNRTXO2IKusYwMFqnhcfLBo=.4055b535-ebb9-41ec-b977-18070e646ae9@github.com>

On Thu, 11 Dec 2025 17:44:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only load _requested_gc_cause once when figuring out pending requests
>
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp line 46:
> 
>> 44: 
>> 45:   ShenandoahSharedFlag               _gc_requested;
>> 46:   Atomic<GCCause::Cause>             _requested_gc_cause;
> 
> `_requested_gc_cause` should always be accessed when holding the `_control_lock`. Making this atomic should not be unnecessary.

Yes, the change to use Atomic for _requested_gc_cause is unnecessary, I have reverted it with a minor change for ShenandoahControlThread to always access  _requested_gc_cause with `_control_lock` held.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28758#discussion_r2611654969

From kdnilsen at openjdk.org  Thu Dec 11 18:54:36 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 18:54:36 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
Message-ID: <1vJOThZHQ4oUjz0K3Q__TNKqQjmamKli559hUQHPaDI=.50025ca8-1309-4d72-aaad-05dd4daf75fb@github.com>

On Wed, 10 Dec 2025 23:50:38 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FRACTIONAL_DENOMINATOR constat
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 306:
> 
>> 304: 
>> 305:   // How much growth in usage before we trigger old collection as a percent of soft_max_capacity
>> 306:   size_t _growth_percent_before_compaction;
> 
> I'd prefer we didn't use the term "compaction". Would replacing it with "collection", as in the comment, work? Or is there a specific reason you want to say "compaction" here?

Thanks.  Replacing with collection.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2611704905

From xpeng at openjdk.org  Thu Dec 11 18:56:15 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 18:56:15 GMT
Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock
 after allocation failure even block parameter is false [v5]
In-Reply-To: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
Message-ID: <cVj6I5zHfpzK4LF8BQ0e6dh5V0vLI72ssWVIV_KF6zI=.98ac2e06-7752-4fc4-8feb-675b7783091e@github.com>

> There is behavior discrepancy between Shenandoah generational mode and non-generational when it handles mutator allocation failure, as stated in the description of [JDK-8373468](https://bugs.openjdk.org/browse/JDK-8373468), in non-generational, the `block` parameter may not always work.
> 
> Further looking into ShenandoahGenerationalControlThread and ShenandoahControlThread, they handle the _requested_gc_cause and ShenandoahHeap::cancelled_cause differently in other places as well, the change in this PR will minimize the gap to unify the behavior, and also fix potentially missed allocation failure notifications in some rare cases for both control threads.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] GHA (includes tier1 but no unit unit with gtest) 
> - [x] gtest

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  format issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28758/files
  - new: https://git.openjdk.org/jdk/pull/28758/files/469dc1fc..085a0497

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

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

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

From kdnilsen at openjdk.org  Thu Dec 11 19:00:14 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 19:00:14 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <-Ma5FOOlP7qtDmaJtpnglct3_plcnFLYnVnUwWdLpTA=.c154aed7-fc00-4011-8d96-8652cc996234@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
 <mKn330cwE09Jyy3Z-RMPNPctRt-Ow8AwNG27EUCsc9s=.beb8b662-842e-41fb-a16f-164454c62bd7@github.com>
 <-Ma5FOOlP7qtDmaJtpnglct3_plcnFLYnVnUwWdLpTA=.c154aed7-fc00-4011-8d96-8652cc996234@github.com>
Message-ID: <cDTu0g9INR1iOgnm0sgU_-gfZB8NqMyUjR15whX1-mY=.c98ec08b-e3d4-4a71-9de7-c25a821b6115@github.com>

On Thu, 11 Dec 2025 00:14:42 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> And make those two consistent with either "percent_live" or "live_percent" below.
>> 
>> (These comments from me actually belong in the .hpp where these are defined.)
>
> I think "percent" at the end makes sense, so "live_percent" and "growth_percent", so only the "initial growth percent" name needs to be adjusted for consistency.

I believe I have made these changes now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2611724273

From wkemper at openjdk.org  Thu Dec 11 20:37:10 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Dec 2025 20:37:10 GMT
Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock
 after allocation failure even block parameter is false [v5]
In-Reply-To: <cVj6I5zHfpzK4LF8BQ0e6dh5V0vLI72ssWVIV_KF6zI=.98ac2e06-7752-4fc4-8feb-675b7783091e@github.com>
References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
 <cVj6I5zHfpzK4LF8BQ0e6dh5V0vLI72ssWVIV_KF6zI=.98ac2e06-7752-4fc4-8feb-675b7783091e@github.com>
Message-ID: <mK8v5VaNG6yNHFi420eyS1Voakb65gDX7H9JthYRAHw=.781134bb-b1c6-448e-af4e-6a73218cdd7d@github.com>

On Thu, 11 Dec 2025 18:56:15 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> There is behavior discrepancy between Shenandoah generational mode and non-generational when it handles mutator allocation failure, as stated in the description of [JDK-8373468](https://bugs.openjdk.org/browse/JDK-8373468), in non-generational, the `block` parameter may not always work.
>> 
>> Further looking into ShenandoahGenerationalControlThread and ShenandoahControlThread, they handle the _requested_gc_cause and ShenandoahHeap::cancelled_cause differently in other places as well, the change in this PR will minimize the gap to unify the behavior, and also fix potentially missed allocation failure notifications in some rare cases for both control threads.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] GHA (includes tier1 but no unit unit with gtest) 
>> - [x] gtest
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format issue

Can you describe the scenario you are trying to fix here? The two control threads have different idle/wakeup conditions.

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

PR Comment: https://git.openjdk.org/jdk/pull/28758#issuecomment-3643683986

From kdnilsen at openjdk.org  Thu Dec 11 21:25:05 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 21:25:05 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <p23BJxk6ElN7XaXTM_17Iuee8XlVpYro0e7DJfBrbfw=.23571a4f-41d5-41f4-be9e-2d9853bc46af@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
 <p23BJxk6ElN7XaXTM_17Iuee8XlVpYro0e7DJfBrbfw=.23571a4f-41d5-41f4-be9e-2d9853bc46af@github.com>
Message-ID: <vm0N_ZVwTsOeKJD86eetDoaKuMTdesRHbhjMG3wOBps=.628a502c-c831-4488-a5fe-ca28a1c58e57@github.com>

On Thu, 11 Dec 2025 15:46:19 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 65:
>> 
>>> 63:           "(Generational mode only) If the usage within old generation "    \
>>> 64:           "has grown by at least this percent of its live memory size "     \
>>> 65:           "at the start of the previous old-generation marking effort, "    \
>> 
>> Did you intend to say "at the _end_ of the previous old-generation marking effort" above?
>
> Actually, since we are using SATB protocol for old marking, the live data is measured as of the start of GC.  (We subtract out the allocations (promotions) that happen during concurrent GC.

It's been my intention to use a SATB measurement of live data, but it looks like that's not yet implemented.  Would like to leave as is for now.  Will address this in a future PR.  For preservation of thoughts on how to do this:
1. At ShenandoahConcurrentGC::op_init_mark(), when we parallel_heap_region_iterate() over ShenandoahInitMarkUpdateRegionStateClosure, we can capture for each heap its "current usage"
2. At ShenandoahOldHeuristics::prepare_for_old_colections(), this is where we currently set_live_bytes_at_last_mark() to the current live in old.
3. At this point, I would like to compute for each old region the difference between its current old used and its old-used-at-start-of-gc (this represents new allocations (promotions) that happened during concurrent old marking).  Subtract the sum of these differences from the live memory calculated today.  This represents the true live memory at start of old marking (according to SATB theory).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2612115759

From kdnilsen at openjdk.org  Thu Dec 11 21:30:28 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 21:30:28 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v6]
In-Reply-To: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
Message-ID: <xqFqmnFOJimBPRlFWPKq2ufWbk0Ch_JSyFIW8-LgfHM=.2058982e-0308-45d0-80ed-293757931207@github.com>

> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
> 
> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 35%, of the memory not live in old at the last marking of old.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Response to reviewer suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28561/files
  - new: https://git.openjdk.org/jdk/pull/28561/files/41a83389..c71969c7

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

  Stats: 46 lines in 7 files changed: 11 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/28561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28561/head:pull/28561

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

From kdnilsen at openjdk.org  Thu Dec 11 21:55:17 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 21:55:17 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v7]
In-Reply-To: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
Message-ID: <DlD5y-9QwDbGc5dcEK7fG9bTi2aIGhjhWDqD3kTkZxw=.a5312fad-d170-4b74-b17f-ec890636cdc3@github.com>

> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
> 
> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 35%, of the memory not live in old at the last marking of old.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  white space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28561/files
  - new: https://git.openjdk.org/jdk/pull/28561/files/c71969c7..ee81bd92

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

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

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

From xpeng at openjdk.org  Thu Dec 11 22:23:00 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 11 Dec 2025 22:23:00 GMT
Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock
 after allocation failure even block parameter is false [v5]
In-Reply-To: <mK8v5VaNG6yNHFi420eyS1Voakb65gDX7H9JthYRAHw=.781134bb-b1c6-448e-af4e-6a73218cdd7d@github.com>
References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
 <cVj6I5zHfpzK4LF8BQ0e6dh5V0vLI72ssWVIV_KF6zI=.98ac2e06-7752-4fc4-8feb-675b7783091e@github.com>
 <mK8v5VaNG6yNHFi420eyS1Voakb65gDX7H9JthYRAHw=.781134bb-b1c6-448e-af4e-6a73218cdd7d@github.com>
Message-ID: <tAIX1jPZbFCRZJ5_McsdHuhw3GexR1wQ7PaTI4n3_z8=.53fbad08-39d7-41d4-805d-422b8f8f53d6@github.com>

On Thu, 11 Dec 2025 20:34:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Can you describe the scenario you are trying to fix here? The two control threads have different idle/wakeup conditions.

The major thing I am fixing in the PR is to make ShenandoahControlThread always honor the `block` parameter. In current impl  ShenandoahControlThread may still block the mutator thread even `block` parameter is `false`, because the ShenandoahControlThread::request_gc blocks the mutator use _gc_waiters_lock for allocation failure; while ShenandoahGenerationalControlThread::request_gc doesn't, it simplify call `notify_cancellation(cause)` if cause is allocation failure.

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

PR Comment: https://git.openjdk.org/jdk/pull/28758#issuecomment-3644032272

From wkemper at openjdk.org  Thu Dec 11 23:15:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 11 Dec 2025 23:15:36 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v7]
In-Reply-To: <DlD5y-9QwDbGc5dcEK7fG9bTi2aIGhjhWDqD3kTkZxw=.a5312fad-d170-4b74-b17f-ec890636cdc3@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <DlD5y-9QwDbGc5dcEK7fG9bTi2aIGhjhWDqD3kTkZxw=.a5312fad-d170-4b74-b17f-ec890636cdc3@github.com>
Message-ID: <CH_QgOyiyviHefrJBtq5Cy6D55Y7PbhXRR1rzgDb0GE=.4c371a84-af25-4aa3-8643-05e70c8ced64@github.com>

On Thu, 11 Dec 2025 21:55:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
>> 
>> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 35%, of the memory not live in old at the last marking of old.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   white space

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28561#pullrequestreview-3569660574

From kdnilsen at openjdk.org  Thu Dec 11 23:15:39 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 23:15:39 GMT
Subject: RFR: 8373225: GenShen: More adaptive old-generation growth
 heuristics [v5]
In-Reply-To: <vm0N_ZVwTsOeKJD86eetDoaKuMTdesRHbhjMG3wOBps=.628a502c-c831-4488-a5fe-ca28a1c58e57@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
 <FXAliLMEx__zz4SV1f3_Wm5keLvrfa-UNhgkotQmAy8=.a439e6bc-3bec-4972-a36a-001cceff1cfa@github.com>
 <lkd3j6TCj7blnbI2n5ctjEuNP5cD9OZt4kceYo7YvYE=.a86ef2d3-8e2b-46fc-a65f-431f7319c4ae@github.com>
 <p23BJxk6ElN7XaXTM_17Iuee8XlVpYro0e7DJfBrbfw=.23571a4f-41d5-41f4-be9e-2d9853bc46af@github.com>
 <vm0N_ZVwTsOeKJD86eetDoaKuMTdesRHbhjMG3wOBps=.628a502c-c831-4488-a5fe-ca28a1c58e57@github.com>
Message-ID: <a9KUuG6xNr7PpymnaiSUD67YJRK862LQg9q6sFZWQHQ=.5a2b8b6f-9450-4aca-849f-f6deb091bbc4@github.com>

On Thu, 11 Dec 2025 21:22:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Actually, since we are using SATB protocol for old marking, the live data is measured as of the start of GC.  (We subtract out the allocations (promotions) that happen during concurrent GC.
>
> It's been my intention to use a SATB measurement of live data, but it looks like that's not yet implemented.  Would like to leave as is for now.  Will address this in a future PR.  For preservation of thoughts on how to do this:
> 1. At ShenandoahConcurrentGC::op_init_mark(), when we parallel_heap_region_iterate() over ShenandoahInitMarkUpdateRegionStateClosure, we can capture for each heap its "current usage"
> 2. At ShenandoahOldHeuristics::prepare_for_old_colections(), this is where we currently set_live_bytes_at_last_mark() to the current live in old.
> 3. At this point, I would like to compute for each old region the difference between its current old used and its old-used-at-start-of-gc (this represents new allocations (promotions) that happened during concurrent old marking).  Subtract the sum of these differences from the live memory calculated today.  This represents the true live memory at start of old marking (according to SATB theory).

used at mark start is basically top at mark start...  That simplifies things.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2612350194

From kdnilsen at openjdk.org  Thu Dec 11 23:18:18 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 11 Dec 2025 23:18:18 GMT
Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during
 rebuild [v4]
In-Reply-To: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com>
References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com>
Message-ID: <rrsxVghkp5pF6jzUyPiqDVNoExOKfJCN_uTKeQTm2Us=.d48c2e16-6700-4c7a-a85e-880923eb3f1a@github.com>

> This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition.
> 
> This addresses a problem that results if available memory is probed while we are rebuilding the freeset.
> 
> Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced.  This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory.  It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Add rebuild synchronization to capacity() and used()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27612/files
  - new: https://git.openjdk.org/jdk/pull/27612/files/8462a290..3c29dc10

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

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

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

From kbarrett at openjdk.org  Fri Dec 12 04:33:50 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 12 Dec 2025 04:33:50 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue [v3]
In-Reply-To: <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
 <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
Message-ID: <fU_Glg_zmNmnP2hB2WUAbOnkeP4OrK_fDfs5r5EzYNU=.2605bc47-ac5c-4627-825d-5582a84e9366@github.com>

On Thu, 11 Dec 2025 16:41:24 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
>> 
>> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
>> 
>> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove virtual from SATBMarkQueueSet::enqueue_completed_buffer

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28755#pullrequestreview-3570252361

From tschatzl at openjdk.org  Fri Dec 12 08:47:15 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 12 Dec 2025 08:47:15 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <YNTlixS3si9IWNoc1zzmpHheowhM8k2pLouvwI7dMFs=.dafe0be6-a17d-43d4-9c21-906729b39b99@github.com>

On Wed, 10 Dec 2025 18:09:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28754#pullrequestreview-3570876100

From iwalulya at openjdk.org  Fri Dec 12 08:50:07 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 12 Dec 2025 08:50:07 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue [v3]
In-Reply-To: <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
 <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
Message-ID: <QhcDULsFiV7z5t__77IBG0hXgNtSMAYN1B-vcIdAjek=.9c57c738-a648-48fd-a7fa-9a695db61b45@github.com>

On Thu, 11 Dec 2025 16:41:24 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
>> 
>> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
>> 
>> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove virtual from SATBMarkQueueSet::enqueue_completed_buffer

Marked as reviewed by iwalulya (Reviewer).

src/hotspot/share/gc/shared/satbMarkQueue.hpp line 60:

> 58:   NONCOPYABLE(SATBMarkQueue);
> 59: 
> 60:   // The buffer.

We could refactor rename to `_buffer` so we don't need the comment above. But that does not have to be done as part of this change.

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

PR Review: https://git.openjdk.org/jdk/pull/28755#pullrequestreview-3570821325
PR Review Comment: https://git.openjdk.org/jdk/pull/28755#discussion_r2613358741

From tschatzl at openjdk.org  Fri Dec 12 08:50:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 12 Dec 2025 08:50:07 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue [v3]
In-Reply-To: <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
 <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
Message-ID: <G33hocjELAKn2PleU4E8arFHf56qM81btVlPUTaqjFc=.97e776e0-cd4e-4275-aff6-9145a3e7da49@github.com>

On Thu, 11 Dec 2025 16:41:24 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
>> 
>> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
>> 
>> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove virtual from SATBMarkQueueSet::enqueue_completed_buffer

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28755#pullrequestreview-3570884669

From tschatzl at openjdk.org  Fri Dec 12 08:53:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 12 Dec 2025 08:53:54 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize [v3]
In-Reply-To: <rdCWi1G7JmoFyUphH7XAfXyADYZznRT1yYJe8m_f8So=.e17c9873-c848-44fe-899f-aae266bba343@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
 <rdCWi1G7JmoFyUphH7XAfXyADYZznRT1yYJe8m_f8So=.e17c9873-c848-44fe-899f-aae266bba343@github.com>
Message-ID: <EYM0gH531Ej4m-qg_YJ5ml0PXMjfkx1qidNZscMBK8Y=.5ac767f0-582e-4459-a7ff-10dfed2cb3b4@github.com>

On Thu, 11 Dec 2025 09:26:32 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this test-only improvement to make TestG1ClassUnloadingHWM.java more robust in various configurations?
>> See https://bugs.openjdk.org/browse/JDK-8373403 for more details.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also check for 'Metadata GC Threshold' for young GC

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28738#pullrequestreview-3570905297

From kbarrett at openjdk.org  Fri Dec 12 09:05:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 12 Dec 2025 09:05:52 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <GnGujdsix-zjHcbaT7V_vfTTZhStvNtim0yjx_LVHVE=.c4786b18-4394-42d4-ab81-0a0e20370f7c@github.com>

On Wed, 10 Dec 2025 18:09:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28754#pullrequestreview-3570946339

From iwalulya at openjdk.org  Fri Dec 12 09:27:53 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 12 Dec 2025 09:27:53 GMT
Subject: RFR: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize [v3]
In-Reply-To: <rdCWi1G7JmoFyUphH7XAfXyADYZznRT1yYJe8m_f8So=.e17c9873-c848-44fe-899f-aae266bba343@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
 <rdCWi1G7JmoFyUphH7XAfXyADYZznRT1yYJe8m_f8So=.e17c9873-c848-44fe-899f-aae266bba343@github.com>
Message-ID: <x6lDngbDTd5BelEUy45JPhar3pVPtoEFC2C7ld58HBs=.7c2e9ba7-84c1-41ff-8e14-d0aa9f878956@github.com>

On Thu, 11 Dec 2025 09:26:32 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this test-only improvement to make TestG1ClassUnloadingHWM.java more robust in various configurations?
>> See https://bugs.openjdk.org/browse/JDK-8373403 for more details.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also check for 'Metadata GC Threshold' for young GC

Looks good!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28738#pullrequestreview-3571024816

From duke at openjdk.org  Fri Dec 12 09:43:31 2025
From: duke at openjdk.org (SilenceZheng66)
Date: Fri, 12 Dec 2025 09:43:31 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
Message-ID: <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>

On Fri, 18 Jul 2025 13:13:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

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

> 1068:     size_policy->sample_old_gen_used_bytes(MAX2(pre_gc_values.old_gen_used(), old_gen->used_in_bytes()));
> 1069: 
> 1070:     if (UseAdaptiveSizePolicy) {

I think this code block could raise heap size don't expand in some specific case, maybe you should optimize it. @albertnetymk

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

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

From kdnilsen at openjdk.org  Fri Dec 12 14:05:35 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 12 Dec 2025 14:05:35 GMT
Subject: Integrated: 8373225: GenShen: More adaptive old-generation growth
 heuristics
In-Reply-To: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
References: <KJx2SjtChP6mWJFA-gViQQJ6ig1vYg24eX7qpPn-3tQ=.74beb540-d6cd-4671-9f1d-7148e4cf66d7@github.com>
Message-ID: <t_EGsHRC6OtpBtzLf-I89GwOlGnGXcemNt6cjGzs8us=.cca07bf3-903c-4b85-ac6c-3d113e5f869a@github.com>

On Sat, 29 Nov 2025 01:10:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
> 
> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 35%, of the memory not live in old at the last marking of old.

This pull request has now been integrated.

Changeset: 41001437
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/410014377c210463d654b841bafbcf36947aa960
Stats:     166 lines in 11 files changed: 106 ins; 7 del; 53 mod

8373225: GenShen: More adaptive old-generation growth heuristics

Reviewed-by: wkemper, ysr

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

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

From wkemper at openjdk.org  Fri Dec 12 16:22:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 12 Dec 2025 16:22:56 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue [v3]
In-Reply-To: <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
 <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
Message-ID: <7Rp3_84SR6Hr-IWJtrT5l7SKUm3M4b8DmL5Y31NXkSc=.9667dc0f-4904-40d0-86e1-3d9a33b23d49@github.com>

On Thu, 11 Dec 2025 16:41:24 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
>> 
>> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
>> 
>> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove virtual from SATBMarkQueueSet::enqueue_completed_buffer

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28755#pullrequestreview-3572619278

From duke at openjdk.org  Fri Dec 12 16:26:52 2025
From: duke at openjdk.org (duke)
Date: Fri, 12 Dec 2025 16:26:52 GMT
Subject: RFR: 8372250: Merge PtrQueue into SATBMarkQueue [v3]
In-Reply-To: <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
 <JgMq-ku_EqJwJCfGKWxQHZsdeZ0W7Bay4BRDVNODJGo=.5bbe3efc-2841-4ff6-9b05-1aecb0aad86e@github.com>
Message-ID: <tQxiw5vCX4xR6JGF6X8pc4dK1vzA2QJUPKPbsfMlbtU=.d632f258-8dd0-43f6-a7a2-02302c5561ed@github.com>

On Thu, 11 Dec 2025 16:41:24 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
>> 
>> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
>> 
>> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove virtual from SATBMarkQueueSet::enqueue_completed_buffer

@benty-amzn 
Your change (at version 517b245fb65eb2b9df0de21e09e016d2129e8edf) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28755#issuecomment-3647258352

From btaylor at openjdk.org  Fri Dec 12 16:31:02 2025
From: btaylor at openjdk.org (Ben Taylor)
Date: Fri, 12 Dec 2025 16:31:02 GMT
Subject: Integrated: 8372250: Merge PtrQueue into SATBMarkQueue
In-Reply-To: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
References: <v6Vh4n3IFfAMs270McqBF1I2OjIo-8nPanhB8f3ES8I=.4f54ff0e-81d3-40cb-bcec-9b72409fa78f@github.com>
Message-ID: <JAGMGuvv7VedqMZEUp0nVYj4yBrWVH496tvLKPu82kg=.a26074c6-4e3a-4e6d-a783-8ff310fd137d@github.com>

On Wed, 10 Dec 2025 18:26:16 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> This change merges `PtrQueue` into its only child class, `SATBMarkQueue`. The corresponding `PtrQueueSet` is merged with `SATBMarkQueueSet`, and `G1SATBMarkQueueSet` and `ShenandoahSATBMarkQueueSet` continue to inherit from that class.
> 
> There are few code modifications - most methods were moved directly from `PtrQueue` to `SATBMarkQueue`. The one meaningful change is to  preserve `SATBMarkQueue`'s call to `filter(queue);` before `flush_queue`. 
> 
> This change passes all tier1 jtreg tests with both Shenandoah and G1 in local testing.

This pull request has now been integrated.

Changeset: 0eb2bcd2
Author:    Ben Taylor <btaylor at openjdk.org>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0eb2bcd260426bc449264b72a2cee8ce109308ee
Stats:     475 lines in 6 files changed: 173 ins; 287 del; 15 mod

8372250: Merge PtrQueue into SATBMarkQueue

Reviewed-by: kbarrett, iwalulya, tschatzl, wkemper

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

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

From manc at openjdk.org  Fri Dec 12 21:22:12 2025
From: manc at openjdk.org (Man Cao)
Date: Fri, 12 Dec 2025 21:22:12 GMT
Subject: Integrated: 8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail
 with large G1HeapRegionSize and small InitialHeapSize
In-Reply-To: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
References: <k7ejgyeHu23a-yx-vRMDPjst4RmEEGLixPivSZKqn7E=.a54a4695-f5fb-44d2-b60f-b34b4afb8737@github.com>
Message-ID: <HEnyd2qd02jNAQQ7ew-fuSfCBWcHWFlFSXx4qv86Qx0=.a92c897b-cd35-48cd-bdb4-0b64d1c6ac9c@github.com>

On Wed, 10 Dec 2025 09:48:44 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this test-only improvement to make TestG1ClassUnloadingHWM.java more robust in various configurations?
> See https://bugs.openjdk.org/browse/JDK-8373403 for more details.
> 
> -Man

This pull request has now been integrated.

Changeset: 23c39757
Author:    Man Cao <manc at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23c39757ecdc834c631f98f4487cfea21c9b948b
Stats:     9 lines in 1 file changed: 2 ins; 0 del; 7 mod

8373403: [TESTBUG] TestG1ClassUnloadingHWM.java could fail with large G1HeapRegionSize and small InitialHeapSize

Reviewed-by: tschatzl, iwalulya

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

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

From jnorlinder at openjdk.org  Fri Dec 12 21:40:04 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 12 Dec 2025 21:40:04 GMT
Subject: RFR: 8373625: CPUTimeCounters creates a total counter for unsupported
 GCs
Message-ID: <GjlK2d3_DK9wq1GaMv616ltPbFnROkCMtz_H9XJaQNU=.4d23e1de-4f9a-423e-ab4c-a89eb835d74c@github.com>

`CPUTimeCounters` unconditionally creates `CPUTimeGroups::CPUTimeType::gc_total`. Since only Parallel and G1 are supported by this framework/class, this leads to publishing a counter that always resolves to 0. This may be contradictory for an end-user especially so as we now support logging GC CPU time for any GC inside Hotspot. For an example using `-XX:+UseZGC -Xlog:cpu` we get


[7.907s][info][cpu] === CPU time Statistics =============================================================
[7.907s][info][cpu]                                                                             CPUs
[7.907s][info][cpu]                                                                s       %  utilized
[7.907s][info][cpu]    Process
[7.907s][info][cpu]      Total                                              186.9562  100.00      23.6
[7.907s][info][cpu]      Garbage Collection                                   0.6700    0.36       0.1
[7.907s][info][cpu]        GC Threads                                         0.6692    0.36       0.1
[7.907s][info][cpu]        VM Thread                                          0.0008    0.00       0.0
[7.907s][info][cpu] =====================================================================================


But `jcmd $(pgrep -n java) PerfCounter.print | grep -E "sun.threads.total_gc_cpu_time"` prints: `sun.threads.total_gc_cpu_time=0`.

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

Commit messages:
 - Only create sun.threads.total_gc_cpu_time if we run a supported GC

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

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

From ysr at openjdk.org  Sat Dec 13 00:06:04 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 13 Dec 2025 00:06:04 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
Message-ID: <fioGJOkNEh0w9JVeYjFf9RAxaIbOWsU7kJH6xyRisB8=.2c288da9-e928-408a-8387-3cb619b1f71e@github.com>

On Fri, 5 Dec 2025 18:53:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> In some cases, the control thread may fail to observe an allocation failure. This results in the thread which failed to allocate waiting forever for the control thread to run a cycle. Depending on which thread fails to allocate, the process may not make progress.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set requested gc cause under a lock when allocation fails

Thanks for cleaning this up.

Did you review the non-generational ShenandoahControlThread and uses thereof to make sure a similar issues doesn't exist there?

As Xiaolong states, it might be worthwhile to do a refactor that shares as much as needed and no more, and to do so cleanly.

This looks good; sorry for the delay in reviewing.

?

src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp line 143:

> 141:   void notify_control_thread(MonitorLocker& ml, GCCause::Cause cause, ShenandoahGeneration* generation);
> 142:   void notify_control_thread(GCCause::Cause cause);
> 143:   void notify_control_thread(MonitorLocker& ml, GCCause::Cause cause);

Nit:

I'd (subjectively) order them thus: (nct = notify_control_thread)

1. nct(cause)
2. nct(ml, cause)
3. nct(cause, generation)
4. nct(ml, cause, generation)

For completeness in the documentation comment preceding, state that if an argument, cause or generation, is missing, it isn't updated.

I am assuming that there is a specific small subset of cause values where the generation isn't important to spell out and really implies "isn't necessary or is implicitly understood" for cancellation/request cause? Is there a call argument/consistency check that might be done in the nct:s where these bottom out to confirm this, or am I being unnecessarily paranoid?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28665#pullrequestreview-3573943496
PR Review Comment: https://git.openjdk.org/jdk/pull/28665#discussion_r2615874522

From wkemper at openjdk.org  Sat Dec 13 00:18:57 2025
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 13 Dec 2025 00:18:57 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <fioGJOkNEh0w9JVeYjFf9RAxaIbOWsU7kJH6xyRisB8=.2c288da9-e928-408a-8387-3cb619b1f71e@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
 <fioGJOkNEh0w9JVeYjFf9RAxaIbOWsU7kJH6xyRisB8=.2c288da9-e928-408a-8387-3cb619b1f71e@github.com>
Message-ID: <QtCfKrCcqCfmDa5DzMgCPKl6lCiZOLhnwT44GEyTzeM=.d44e5cd1-0cde-4d77-9366-18d9d88147ff@github.com>

On Sat, 13 Dec 2025 00:03:10 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:
>> 
>>   Set requested gc cause under a lock when allocation fails
>
> Thanks for cleaning this up.
> 
> Did you review the non-generational ShenandoahControlThread and uses thereof to make sure a similar issues doesn't exist there?
> 
> As Xiaolong states, it might be worthwhile to do a refactor that shares as much as needed and no more, and to do so cleanly.
> 
> This looks good; sorry for the delay in reviewing.
> 
> ?

@ysramakrishna , @pengxiaolong - The non-generational control thread is less susceptible to this sort of issue because it has the responsibility of evaluating trigger conditions. It's loop therefore sleeps with a timed wait when the GC cycle is complete. If it misses a cancelled gc request, it will see it on the next iteration.

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

PR Comment: https://git.openjdk.org/jdk/pull/28665#issuecomment-3648576231

From wkemper at openjdk.org  Sat Dec 13 00:25:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 13 Dec 2025 00:25:56 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v2]
In-Reply-To: <fioGJOkNEh0w9JVeYjFf9RAxaIbOWsU7kJH6xyRisB8=.2c288da9-e928-408a-8387-3cb619b1f71e@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <iX4fDRFf1MLmmuecADh4p4283Yjc07sIFSR5vhlpMiA=.29b0001e-0c16-47f1-856f-2ab2a0e34b9a@github.com>
 <fioGJOkNEh0w9JVeYjFf9RAxaIbOWsU7kJH6xyRisB8=.2c288da9-e928-408a-8387-3cb619b1f71e@github.com>
Message-ID: <bwsAZOSh2GLT_hlzbocecmrW3bNbNqH-wK1h8PiO0dw=.8d700775-ee88-4e93-a2ee-38357f9c2829@github.com>

On Fri, 12 Dec 2025 23:57:50 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:
>> 
>>   Set requested gc cause under a lock when allocation fails
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp line 143:
> 
>> 141:   void notify_control_thread(MonitorLocker& ml, GCCause::Cause cause, ShenandoahGeneration* generation);
>> 142:   void notify_control_thread(GCCause::Cause cause);
>> 143:   void notify_control_thread(MonitorLocker& ml, GCCause::Cause cause);
> 
> Nit:
> 
> I'd (subjectively) order them thus: (nct = notify_control_thread)
> 
> 1. nct(cause)
> 2. nct(ml, cause)
> 3. nct(cause, generation)
> 4. nct(ml, cause, generation)
> 
> For completeness in the documentation comment preceding, state that if an argument, cause or generation, is missing, it isn't updated.
> 
> I am assuming that there is a specific small subset of cause values where the generation isn't important to spell out and really implies "isn't necessary or is implicitly understood" for cancellation/request cause? Is there a call argument/consistency check that might be done in the nct:s where these bottom out to confirm this, or am I being unnecessarily paranoid?

Yes, there are two uses where we don't need the generation:
* It's important to _not_ update the generation for an allocation failure (degenerated cycle needs to use same generation)
* We are shutting down the JVM and don't want to start another cycle.

All cases need to pass a `GCCause`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28665#discussion_r2615896228

From wkemper at openjdk.org  Sat Dec 13 00:44:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 13 Dec 2025 00:44:21 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v3]
In-Reply-To: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
Message-ID: <u-GdY5Bv_UIO_ClAmPtyZT94Arz9eEAzqMDTwEQaIWA=.9d326ab3-fab7-4ee9-a822-f431a6c0ab8c@github.com>

> In some cases, the control thread may fail to observe an allocation failure. This results in the thread which failed to allocate waiting forever for the control thread to run a cycle. Depending on which thread fails to allocate, the process may not make progress.

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

 - Merge remote-tracking branch 'jdk/master' into fix-missed-cancellation
 - Improve comment
 - Set requested gc cause under a lock when allocation fails
 - Expand scope of control lock so that it can't miss cancellation notifications

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28665/files
  - new: https://git.openjdk.org/jdk/pull/28665/files/1081f21e..4c82d21c

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

  Stats: 35761 lines in 486 files changed: 23753 ins; 9524 del; 2484 mod
  Patch: https://git.openjdk.org/jdk/pull/28665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28665/head:pull/28665

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

From ysr at openjdk.org  Sat Dec 13 00:44:21 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 13 Dec 2025 00:44:21 GMT
Subject: RFR: 8373100: Genshen: Control thread can miss allocation failure
 notification [v3]
In-Reply-To: <u-GdY5Bv_UIO_ClAmPtyZT94Arz9eEAzqMDTwEQaIWA=.9d326ab3-fab7-4ee9-a822-f431a6c0ab8c@github.com>
References: <0zYhRl0mOYzH1sYZRFhxfr06N5-5Kh78wCVSCfVA2Qo=.7583bd34-3e9a-4f8e-a274-d1d2ba09a442@github.com>
 <u-GdY5Bv_UIO_ClAmPtyZT94Arz9eEAzqMDTwEQaIWA=.9d326ab3-fab7-4ee9-a822-f431a6c0ab8c@github.com>
Message-ID: <L5ELacgm8AbdEDlOCVf5XJ2bC6nPcuRel7xSiyzaxXI=.1a02f9df-a400-4f47-b511-02f347b3c78d@github.com>

On Sat, 13 Dec 2025 00:41:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> In some cases, the control thread may fail to observe an allocation failure. This results in the thread which failed to allocate waiting forever for the control thread to run a cycle. Depending on which thread fails to allocate, the process may not make progress.
>
> 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into fix-missed-cancellation
>  - Improve comment
>  - Set requested gc cause under a lock when allocation fails
>  - Expand scope of control lock so that it can't miss cancellation notifications

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28665#pullrequestreview-3573980764

From ayang at openjdk.org  Sat Dec 13 02:07:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 13 Dec 2025 02:07:07 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
Message-ID: <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>

On Fri, 12 Dec 2025 09:37:48 GMT, SilenceZheng66 <duke 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 33 commits:
>> 
>>  - merge
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1070:
> 
>> 1068:     size_policy->sample_old_gen_used_bytes(MAX2(pre_gc_values.old_gen_used(), old_gen->used_in_bytes()));
>> 1069: 
>> 1070:     if (UseAdaptiveSizePolicy) {
> 
> I think this code block could raise heap size don't expand in some specific case, maybe you should optimize it. @albertnetymk

@SilenceZheng66 Could you elaborate the issue, ideally, in a JBS ticket? (A reproducer/gc-log would be nice, but detailed description works as well.)

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

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

From ayang at openjdk.org  Mon Dec 15 00:18:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 15 Dec 2025 00:18:11 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
 [v2]
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

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
 - pgc-obsolete-array-chunk

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

Changes: https://git.openjdk.org/jdk/pull/28754/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28754&range=01
  Stats: 10 lines in 3 files changed: 2 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28754/head:pull/28754

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

From kbarrett at openjdk.org  Mon Dec 15 01:42:40 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Dec 2025 01:42:40 GMT
Subject: RFR: 8372564: Convert StringDedup to use Atomic<T> [v2]
In-Reply-To: <voobFETMOEBS-cmAzhAZTo5Gv2vAUARRELQAUyEF9Zk=.309cf890-2d32-4e0b-8f52-dc7f1610b314@github.com>
References: <voobFETMOEBS-cmAzhAZTo5Gv2vAUARRELQAUyEF9Zk=.309cf890-2d32-4e0b-8f52-dc7f1610b314@github.com>
Message-ID: <0Nt1O86jsSN0ZdxWM9d5EBaScK0T4IYW9Z4ZrByDgdI=.545332e3-d836-427a-8ae5-1fcc7e4b1333@github.com>

> Please review this change to StringDedup to use Atomic rather than directly
> applying AtomicAccess to volatile members.
> 
> Testing: mach5 tier1-5

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

 - Merge branch 'master' into stringdedup-atomic
 - remove use of DeferredStatic
 - Merge branch 'master' into stringdedup-atomic
 - stringdedup uses Atomic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28524/files
  - new: https://git.openjdk.org/jdk/pull/28524/files/a14d77ce..01c0b461

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

  Stats: 59697 lines in 1039 files changed: 37648 ins; 16991 del; 5058 mod
  Patch: https://git.openjdk.org/jdk/pull/28524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28524/head:pull/28524

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

From kbarrett at openjdk.org  Mon Dec 15 01:42:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Dec 2025 01:42:41 GMT
Subject: RFR: 8372564: Convert StringDedup to use Atomic<T> [v2]
In-Reply-To: <rUOvkZX1AMkRiaIz7lDIpnuEI83ziE7WZJmWpx8jZRg=.6239ffc8-fd91-4809-b152-71b48bfeca4f@github.com>
References: <voobFETMOEBS-cmAzhAZTo5Gv2vAUARRELQAUyEF9Zk=.309cf890-2d32-4e0b-8f52-dc7f1610b314@github.com>
 <iOuGDyWZxhs11NwzIwazTM0UjDLAK1NkRZk75bgK7m4=.f9de3c91-1af9-42cd-8dba-5f6368260c5a@github.com>
 <_pWUrDZNFKCxiG1getksYdzBTn4TM4UDiq5Hb3quOCY=.3fef7887-2b1c-4364-bd9e-2aa9fa7a3562@github.com>
 <rUOvkZX1AMkRiaIz7lDIpnuEI83ziE7WZJmWpx8jZRg=.6239ffc8-fd91-4809-b152-71b48bfeca4f@github.com>
Message-ID: <2Dt69dMgOhOZYyfxDZqOzMp3Td86Eknx8wjAaBIKcHU=.e0c9c08a-aaea-41b3-a9da-4d1977d2fbac@github.com>

On Tue, 2 Dec 2025 15:45:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> The Style Guide says
>> 
>> "Variables with static storage duration and _dynamic initialization_
>> [C++14 3.6.2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf)).
>> should be avoided, unless an implementation is permitted to perform the
>> initialization as a static initialization."
>> 
>> It may not be immediately obvious whether dynamic initialization is required.
>> (Currently, a non-local Atomic has dynamic initialization that is likely
>> reducible to static initialization when the ctor argument is a constant.
>> Making the Atomic ctors constexpr would make most such static. Translated
>> Atomics might also need the decay function to be constexpr.)
>> 
>> So the safe thing to do in this respect is to use DeferredStatic for a
>> non-local variable of class type. Of course, then you need to find a good
>> place to put the initialization. That already existed in the case at hand.
>
> We discussed this a bit more, and decided to make the Atomic ctors constexpr
> so that, with constant arguments, they are guaranteed to be static initialized.
> And then change this to remove the use of DeferredStatic and instead have the
> uses assert non-null the way they used to, instead of using the DeferredStatic
> initialization check. The benefit is that many uses of non-local Atomic
> definitely don't need the additional DeferredStatic ceremony.

I've removed the use of DeferredStatic.  Constant initialization of Atomic isn't guaranteed yet (needs https://github.com/openjdk/jdk/pull/28711), but zero initialization is sufficient for our needs here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28524#discussion_r2617706903

From kbarrett at openjdk.org  Mon Dec 15 01:47:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Dec 2025 01:47:52 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
 [v2]
In-Reply-To: <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
 <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>
Message-ID: <i5Lvyz5FGZ5LxKMHla9jOw2QiBFSF6--C_cHCyDS1Sg=.0a55fc53-ebd5-4fea-a54e-1a899b24827c@github.com>

On Mon, 15 Dec 2025 00:18:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Obsolete a deprecated jvm flag. Its default value is `true`.
>> 
>> Test: tier1-3
>
> 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
>  - pgc-obsolete-array-chunk

Still good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28754#pullrequestreview-3576136852

From ayang at openjdk.org  Mon Dec 15 01:53:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 15 Dec 2025 01:53:05 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
 [v2]
In-Reply-To: <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
 <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>
Message-ID: <I1DkhLd4hja95zBkj6-Wp5Z85uPbt0R0834eI3r5R9c=.6a0cadb7-6bd1-4f9e-bd8e-77b5fb8ceb1a@github.com>

On Mon, 15 Dec 2025 00:18:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Obsolete a deprecated jvm flag. Its default value is `true`.
>> 
>> Test: tier1-3
>
> 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
>  - pgc-obsolete-array-chunk

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28754#issuecomment-3652578437

From ayang at openjdk.org  Mon Dec 15 01:53:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 15 Dec 2025 01:53:06 GMT
Subject: Integrated: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <NP1s02VKTR3X7kFZDEOp268Rg5z05pj80hpbYxM1Lto=.79a0038f-d869-44d9-980d-06969dbe9b7b@github.com>

On Wed, 10 Dec 2025 18:09:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

This pull request has now been integrated.

Changeset: eda1ab21
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eda1ab2143f8bb25fce2e5c086aeb4ecb4141f55
Stats:     10 lines in 3 files changed: 2 ins; 6 del; 2 mod

8373449: Parallel: Obsolete deprecated PSChunkLargeArrays

Reviewed-by: kbarrett, dholmes, tschatzl

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

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