From kbarrett at openjdk.org  Wed Oct  1 06:14:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 1 Oct 2025 06:14:56 GMT
Subject: RFR: 8368957: Remove metaprogramming/logical.hpp in favor of C++17
 facilities
In-Reply-To: <Vl5yANLdRR41zJBiY5DYG8CGF7C_hPS5lbmGMiL0Fw4=.7e22de86-3f73-4ed3-9451-69bbba0e71c0@github.com>
References: <ZWd_O7Gh-6HJeRPBnM-oYuLFq6S1xc1HwaLyia3Dqdo=.b8fa2145-e4e8-4acd-bbc8-544ee11873d9@github.com>
 <Vl5yANLdRR41zJBiY5DYG8CGF7C_hPS5lbmGMiL0Fw4=.7e22de86-3f73-4ed3-9451-69bbba0e71c0@github.com>
Message-ID: <DcSuvDA6BwFFOAd_c0mPFTU-Qdq0TthJwSNr-9EllIA=.43135eb5-b975-4a61-ac6e-cec6aee68978@github.com>

On Tue, 30 Sep 2025 14:08:01 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Please review this trivial change to remove metaprogramming/logical.hpp and
>> its associated gtest, after first updating the one lingering use.
>> 
>> Testing: mach5 tier1
>
> Marked as reviewed by mchevalier (Committer).

Thanks for reviews @marc-chevalier and @walulyai

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

PR Comment: https://git.openjdk.org/jdk/pull/27578#issuecomment-3354886308

From kbarrett at openjdk.org  Wed Oct  1 06:14:57 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 1 Oct 2025 06:14:57 GMT
Subject: Integrated: 8368957: Remove metaprogramming/logical.hpp in favor of
 C++17 facilities
In-Reply-To: <ZWd_O7Gh-6HJeRPBnM-oYuLFq6S1xc1HwaLyia3Dqdo=.b8fa2145-e4e8-4acd-bbc8-544ee11873d9@github.com>
References: <ZWd_O7Gh-6HJeRPBnM-oYuLFq6S1xc1HwaLyia3Dqdo=.b8fa2145-e4e8-4acd-bbc8-544ee11873d9@github.com>
Message-ID: <Lm46X3KoCPCf0KurlKOOUNcfx2W2dL5GiDHNikIzQ20=.110c8eba-36bb-4081-9f1b-868d683a47b1@github.com>

On Tue, 30 Sep 2025 13:50:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove metaprogramming/logical.hpp and
> its associated gtest, after first updating the one lingering use.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: 394eb80a
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/394eb80a48fa73238cf897087b99c3da5a616566
Stats:     159 lines in 3 files changed: 2 ins; 155 del; 2 mod

8368957: Remove metaprogramming/logical.hpp in favor of C++17 facilities

Reviewed-by: mchevalier, iwalulya

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

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

From tschatzl at openjdk.org  Wed Oct  1 08:11:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 1 Oct 2025 08:11:07 GMT
Subject: RFR: 8368954: G1: Document why G1 uses TLS storage for the current
 card table reference [v2]
In-Reply-To: <nQQylY646VcAEk6E7NTrdc27KTfDlGYiXPq-iQh0-5I=.359f8820-f425-460a-b6fb-b7597860bb6b@github.com>
References: <JXTrZcSVM9q-sf_445VqrTzmLW78R-rHH-JvfACtXVA=.b50ad106-1afc-47ff-a320-9079ac729087@github.com>
 <nQQylY646VcAEk6E7NTrdc27KTfDlGYiXPq-iQh0-5I=.359f8820-f425-460a-b6fb-b7597860bb6b@github.com>
Message-ID: <RXSCjkjo9a0Y9uEo2npufZYhubl3Twn87rXTLFMAszs=.0a1fdcf3-10ca-4b41-83c7-2b3de7857a9c@github.com>

On Tue, 30 Sep 2025 11:51:52 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/gc/g1/g1ThreadLocalData.hpp
>
> Marked as reviewed by rcastanedalo (Reviewer).

Thanks @robcasloz @walulyai @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/27573#issuecomment-3355215843

From tschatzl at openjdk.org  Wed Oct  1 08:11:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 1 Oct 2025 08:11:07 GMT
Subject: RFR: 8368953: Document the reason why Serial/Parallel/G1 use zero
 as dirty card value [v2]
In-Reply-To: <9E5nTM1Kfguvi18JFVNgIhF1eWE-Zp0JByAmAaqIYvI=.95247849-90a8-4c2b-a46f-52756778917a@github.com>
References: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com>
 <VePX3dH1y7-MRjBwqzSIIBPGeDGtXtNJri8g62pm8fs=.05f07339-a58b-4297-b635-a677e4186c5f@github.com>
 <9E5nTM1Kfguvi18JFVNgIhF1eWE-Zp0JByAmAaqIYvI=.95247849-90a8-4c2b-a46f-52756778917a@github.com>
Message-ID: <su0w2_13sRlRUsRUqejTsZ90wNL2teiiiCW0FYHEUdQ=.e4e1e8d7-d882-47fd-bd14-b42433ebe265@github.com>

On Tue, 30 Sep 2025 19:13:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/gc/shared/cardTable.hpp
>>  - Update src/hotspot/share/gc/shared/cardTable.hpp
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @walulyai for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/27575#issuecomment-3355214709

From tschatzl at openjdk.org  Wed Oct  1 08:11:09 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 1 Oct 2025 08:11:09 GMT
Subject: Integrated: 8368954: G1: Document why G1 uses TLS storage for the
 current card table reference
In-Reply-To: <JXTrZcSVM9q-sf_445VqrTzmLW78R-rHH-JvfACtXVA=.b50ad106-1afc-47ff-a320-9079ac729087@github.com>
References: <JXTrZcSVM9q-sf_445VqrTzmLW78R-rHH-JvfACtXVA=.b50ad106-1afc-47ff-a320-9079ac729087@github.com>
Message-ID: <HJQr5BPqspk21gkuZqqddYjK-Dp0N6Xwgquebq1r5sg=.c77a59db-e8f5-440f-bad2-e672512c4b7c@github.com>

On Tue, 30 Sep 2025 11:27:46 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review some documentation update why G1 now uses TLS storage to get the current card table base value for the card mark.
> 
> TLDR: it's the overall fastest currently available way.
> 
> Testing: local compilation, this is just a trivial documentation change.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 1188ca55
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1188ca55f525554d2bb10691b368c818d98e5ea7
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8368954: G1: Document why G1 uses TLS storage for the current card table reference

Reviewed-by: ayang, rcastanedalo, iwalulya

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

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

From tschatzl at openjdk.org  Wed Oct  1 08:11:09 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 1 Oct 2025 08:11:09 GMT
Subject: Integrated: 8368953: Document the reason why Serial/Parallel/G1 use
 zero as dirty card value
In-Reply-To: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com>
References: <52vrwVAnYa__vQf-giR4Yb3G_NWFfArR_LtLXW-syX0=.eafffb44-6c22-4551-b484-06031adf30ae@github.com>
Message-ID: <eg8cDE1VUAETUMQkwRA08HijxcTpDuHKiupI4mWePbM=.ec9ef1cf-84fa-4613-8aca-01042993e945@github.com>

On Tue, 30 Sep 2025 11:43:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial change to document the reason for the dirty/clean card value selection.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

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

8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value

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

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

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

From fandreuzzi at openjdk.org  Wed Oct  1 09:08:09 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 1 Oct 2025 09:08:09 GMT
Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in
 shenandoahSTWMark
Message-ID: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>

Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. 

- `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`.
- `nworkers` is guaranteed to be > 0

Passes `tier1` and `tier2` (fastdebug).

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

Commit messages:
 - trigger
 - replace

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

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

From shade at openjdk.org  Wed Oct  1 09:15:31 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 1 Oct 2025 09:15:31 GMT
Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in shenandoahSTWMark
In-Reply-To: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
References: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
Message-ID: <Ssko4qRruX9TCFbkft7id9ZLtDf1X6YhKYO-xFZ_2Co=.e0b17868-a532-488b-bbe4-1fd27bf4c9e9@github.com>

On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. 
> 
> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`.
> - `nworkers` is guaranteed to be > 0
> 
> Passes `tier1` and `tier2` (fastdebug).

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27589#pullrequestreview-3288228821

From ayang at openjdk.org  Wed Oct  1 09:22:26 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 1 Oct 2025 09:22:26 GMT
Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in shenandoahSTWMark
In-Reply-To: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
References: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
Message-ID: <qwgjb2YHM1j3jk1WLYBjgRiwlB6BzvRJ512fIVB3mKc=.6cbad021-5788-4069-9b27-3e81299774fc@github.com>

On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. 
> 
> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`.
> - `nworkers` is guaranteed to be > 0
> 
> Passes `tier1` and `tier2` (fastdebug).

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27589#pullrequestreview-3288254141

From fandreuzzi at openjdk.org  Thu Oct  2 08:38:31 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 2 Oct 2025 08:38:31 GMT
Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in shenandoahSTWMark
In-Reply-To: <qwgjb2YHM1j3jk1WLYBjgRiwlB6BzvRJ512fIVB3mKc=.6cbad021-5788-4069-9b27-3e81299774fc@github.com>
References: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
 <qwgjb2YHM1j3jk1WLYBjgRiwlB6BzvRJ512fIVB3mKc=.6cbad021-5788-4069-9b27-3e81299774fc@github.com>
Message-ID: <eKKw-zvBcoVYVSMkK8Sl6nUgz7a1rkWaiNJzcZoEnGM=.d7ac3ca0-f552-4bd3-99c9-ffb6aec8f525@github.com>

On Wed, 1 Oct 2025 09:19:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. 
>> 
>> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`.
>> - `nworkers` is guaranteed to be > 0
>> 
>> Passes `tier1` and `tier2` (fastdebug).
>
> Marked as reviewed by ayang (Reviewer).

Thanks for the review @albertnetymk and @shipilev.

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

PR Comment: https://git.openjdk.org/jdk/pull/27589#issuecomment-3359876182

From duke at openjdk.org  Thu Oct  2 08:38:33 2025
From: duke at openjdk.org (duke)
Date: Thu, 2 Oct 2025 08:38:33 GMT
Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in shenandoahSTWMark
In-Reply-To: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
References: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
Message-ID: <GTd6y8SfL7SpRwS_1Cj0YGFCnah_fJvioZAVZAc5avU=.8f5b89ea-bd29-4081-bd53-6e122bbfca08@github.com>

On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. 
> 
> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`.
> - `nworkers` is guaranteed to be > 0
> 
> Passes `tier1` and `tier2` (fastdebug).

@fandreuz 
Your change (at version 442bc5be6ca713c7fcabf8a0ad87f74f97d58181) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27589#issuecomment-3359879615

From aboldtch at openjdk.org  Thu Oct  2 08:50:54 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 2 Oct 2025 08:50:54 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
Message-ID: <oHkWT0OnLXku6g8FOe6V7eKTdjgdjJ-1f6FmJabHv8Q=.16d5035f-2d58-4f8e-972e-d77786e2eb5e@github.com>

On Thu, 18 Sep 2025 15:37:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN.
>> The acceptable value is changed to 64K.
>> 
>> Tests:
>> linux-x64 tier1
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed MAX2 template parameter

The implementation looks correct now and the extra asserts when calling `try_reserve_range` are a good improvement.

I am still unsure what this flag is supposed to mean. If it is just a hint we allow the user to give or if it is a requirement. And is it for all heaps, or only heaps with +UseCompressedOops as it is currently being used. (Depending on the answers here, we have bugs)

Then there is the whole constraining a JVM advance option process. See my comment in the code. But I would like this PR to also be approved by someone with a better understanding of this process.

src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 292:

> 290:                         "Sum of HeapBaseMinAddress (%zu) and MaxHeapSize (%zu) results in an overflow (%zu)\n",
> 291:                         value , MaxHeapSize, value + MaxHeapSize);
> 292:     return JVMFlag::VIOLATES_CONSTRAINT;

I do not feel like I understand enough of our process when it comes to constraining the JVMs advance options. Even when constraining the nonsensical inputs.

The reasons I am hesitant is that I do not understand this flag at all given that we have this code which ignores the value completely. 
https://github.com/afshin-zafari/jdk/blob/3dfa9765b1d6dcd27152bbd2d242209c7748c964/src/hotspot/share/memory/memoryReserver.cpp#L639-L644

So if we did not have the overflow bug in the code, using a too large value would reach that point and put the heap at arbitrary address which is lower than HeapBaseMinAddress.

Also HeapBaseMinAddress is only used for CompressedOops, so I am not sure if we should constrain the value when CompressedOops are not in use. However this goes back to the whole point of how we treat changing constraints on VM options. Should there always be a CSR?

Example of observed change in behaviour:
## Before

[ linux-x64-debug]$ ./images/jdk/bin/java -XX:HeapBaseMinAddress=18446708889337462784 -Xmx64T --version
java 26-internal 2026-03-17
Java(TM) SE Runtime Environment (fastdebug build 26-internal-2025-09-26-0639506...)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 26-internal-2025-09-26-0639506..., mixed mode, sharing)

## After

[ linux-x64-debug]$ ./images/jdk/bin/java -XX:HeapBaseMinAddress=18446708889337462784 -Xmx64T --version
Sum of HeapBaseMinAddress (18446708889337462784) and MaxHeapSize (70368744177664) results in an overflow (35184372088832)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3293345884
PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2397792042

From fandreuzzi at openjdk.org  Thu Oct  2 09:31:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 2 Oct 2025 09:31:05 GMT
Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in shenandoahSTWMark [v2]
In-Reply-To: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
References: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
Message-ID: <TaOBE2ob0qZv5SiR_QAFCuE6i-1tgwEZwaRaEmSkbZI=.c80e8031-213a-4975-a7bf-ca811a54db81@github.com>

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. 
> 
> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`.
> - `nworkers` is guaranteed to be > 0
> 
> Passes `tier1` and `tier2` (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  trigger

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27589/files
  - new: https://git.openjdk.org/jdk/pull/27589/files/442bc5be..0801a496

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

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

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

From fandreuzzi at openjdk.org  Thu Oct  2 09:31:06 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 2 Oct 2025 09:31:06 GMT
Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in shenandoahSTWMark
In-Reply-To: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
References: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
Message-ID: <WzODYzaiCbkxodfYf5bZNyA0PCQ2Ume2bv9-eYoEYSw=.eed9a252-9666-4007-b7cd-6507e5cc43ff@github.com>

On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. 
> 
> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`.
> - `nworkers` is guaranteed to be > 0
> 
> Passes `tier1` and `tier2` (fastdebug).

I noticed one of the macOS job was canceled, I noticed the same issue in another repository yesterday. I assume the reason is a scheduling timeout.

Restarted GHA run.

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

PR Comment: https://git.openjdk.org/jdk/pull/27589#issuecomment-3360118706

From jsikstro at openjdk.org  Thu Oct  2 09:39:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 2 Oct 2025 09:39:03 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v6]
In-Reply-To: <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
Message-ID: <8eWze_-jDaiR6YqPIXO69uHyMLQUSG_0wM3jyTmYYN4=.bf449c42-7659-498f-b7f3-c8f3073b36d5@github.com>

On Thu, 25 Sep 2025 11:14:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - page-size
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - pgc-largepage

Reviewing this is taking some time, so this is not a full review yet, but so far I have some comments:

Why do we need the dance with Parallel being able to set a specific `desired_page_size` in `Universe::reserve_heap()`? Maybe I'm wrong, but would it not work to disable UseLargePages early and not have specific logic for Parallel?

src/hotspot/share/gc/parallel/mutableSpace.hpp line 65:

> 63: 
> 64: protected:
> 65:   size_t page_size() const                           { return _page_size;         }

We should vertically align this with the other blocks.

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

> 129:   if (page_sz == os::vm_page_size()) {
> 130:     log_warning(gc, heap)("MinHeapSize (%zu) must be large enough for 4 * page-size; Disabling UseLargePages for heap", MinHeapSize);
> 131:     return;

Wouldn't it make sense to do `FLAG_SET_ERGO(UseLargepages, false)` here since it is effectively disabled.

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

> 135:   assert(is_power_of_2((intptr_t)page_sz), "must be a power of 2");
> 136:   // Space is largepage-aligned.
> 137:   size_t new_alignment = page_sz;

To me it looks like new_alignment will always be different from SpaceAlignment here. We could simplify this to the following:


  SpaceAlignment = page_sz;
    
  // Redo everything from the start
  initialize_heap_flags_and_sizes_one_pass();

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

PR Review: https://git.openjdk.org/jdk/pull/26700#pullrequestreview-3252288423
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2397598451
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2397910679
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2397931660

From jsikstro at openjdk.org  Thu Oct  2 09:39:08 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 2 Oct 2025 09:39:08 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v5]
In-Reply-To: <efj4I-AQCWeV4pf8PLDh9jYE3BAmdjx6lCfGXfKoDpc=.81f5b311-55a0-438d-a1b5-3fc6cc0e2590@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <efj4I-AQCWeV4pf8PLDh9jYE3BAmdjx6lCfGXfKoDpc=.81f5b311-55a0-438d-a1b5-3fc6cc0e2590@github.com>
Message-ID: <FwVMXkjuVAm0j6zFYNoe2M8BZeWNlaAukeKtHnH-C7k=.35ff0a5d-306d-452a-8721-e23be451e728@github.com>

On Mon, 15 Sep 2025 13:26:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - page-size
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - pgc-largepage

src/hotspot/share/gc/parallel/psVirtualspace.hpp line 44:

> 42:   const size_t _alignment;
> 43: 
> 44:   // OS page size used. If using transparent large pages, it's the desired large page-size.

I'd change this to say Transparent Huge Pages instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2367988953

From ayang at openjdk.org  Thu Oct  2 10:10:27 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Oct 2025 10:10:27 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v7]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <phwjjF8LGJJKOZiAIjDWwGRTKGaNCS2xliut1mhS09U=.573f1aad-835f-43d1-a108-5a297527c1b1@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

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

 - review
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - page-size
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - pgc-largepage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/5c02c752..2ccd0dd6

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

  Stats: 11612 lines in 377 files changed: 6346 ins; 3098 del; 2168 mod
  Patch: https://git.openjdk.org/jdk/pull/26700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700

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

From ayang at openjdk.org  Thu Oct  2 10:10:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Oct 2025 10:10:30 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v6]
In-Reply-To: <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
Message-ID: <JBMtIjzwgyLJjtmogyRqb0E3_k-_Nn-fXHrJy2PYbQY=.acaa8d43-9add-410e-8e54-55de9ad6dac4@github.com>

On Thu, 25 Sep 2025 11:14:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - page-size
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - pgc-largepage

> Why do we need the dance with Parallel being able to set a specific desired_page_size in Universe::reserve_heap()?

Because heap contains subspaces (eden,from,to,old) which needs to be larger than a OS-page in Parallel. Maybe this doesn't have to be this way, but that's what Parallel NUMA relies on currently. It would be much more invasive to change that.

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

PR Review: https://git.openjdk.org/jdk/pull/26700#pullrequestreview-3293684851

From ayang at openjdk.org  Thu Oct  2 10:10:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Oct 2025 10:10:32 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v6]
In-Reply-To: <8eWze_-jDaiR6YqPIXO69uHyMLQUSG_0wM3jyTmYYN4=.bf449c42-7659-498f-b7f3-c8f3073b36d5@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
 <8eWze_-jDaiR6YqPIXO69uHyMLQUSG_0wM3jyTmYYN4=.bf449c42-7659-498f-b7f3-c8f3073b36d5@github.com>
Message-ID: <TydqjZ-401J-3RByzvnMJz8zqHPWLfGjx7GeZddD15E=.a178114b-8423-4c60-8833-3ba04de7e9a4@github.com>

On Thu, 2 Oct 2025 09:11:51 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into pgc-largepage
>>  - Merge branch 'master' into pgc-largepage
>>  - page-size
>>  - Merge branch 'master' into pgc-largepage
>>  - Merge branch 'master' into pgc-largepage
>>  - Merge branch 'master' into pgc-largepage
>>  - pgc-largepage
>
> src/hotspot/share/gc/parallel/parallelArguments.cpp line 131:
> 
>> 129:   if (page_sz == os::vm_page_size()) {
>> 130:     log_warning(gc, heap)("MinHeapSize (%zu) must be large enough for 4 * page-size; Disabling UseLargePages for heap", MinHeapSize);
>> 131:     return;
> 
> Wouldn't it make sense to do `FLAG_SET_ERGO(UseLargepages, false)` here since it is effectively disabled.

There are non-heap uses of `UseLargePages` as well. Here we concluded heap can't use large-page, but other systems still can.

> To me it looks like new_alignment will always be different from SpaceAlignment here. 

Why so? (I know the default value of SpaceAlignment is 64K*8 bytes, which is not a common large-page-size, but that info is not directly accessible in this context.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2398090623
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2398130690

From ayang at openjdk.org  Thu Oct  2 11:26:57 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Oct 2025 11:26:57 GMT
Subject: RFR: 8369041: Release memory after testing in ThreadsRunner.java
Message-ID: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>

Small patch of cleaning up no longer used data structures after testing is complete. 

Test: tier1-5

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

Commit messages:
 - stress-free-memory

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

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

From fandreuzzi at openjdk.org  Thu Oct  2 12:29:20 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 2 Oct 2025 12:29:20 GMT
Subject: RFR: 8369038: Use NMethodMarkingScope and ThreadsClaimTokenScope in
 psParallelCompact
Message-ID: <eT9xDOq9N5lTljzrq1Ic7NLh6m_ZEDyRvTzSNYw1xfA=.5686b227-c768-4c85-9e58-0c765be180a4@github.com>

Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `MarkFromRootsTask ` to be more precise with what is needed and why.

- `MarkFromRootsTask` uses `MarkingNMethodClosure` (in `PCAddThreadRootsMarkingTaskClosure`), so we also need `NMethodMarkingScope`.
- `active_workers ` is guaranteed to be `> 0`

Passes tier1 and tier2 (fastdebug).

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

Commit messages:
 - replace

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

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

From duke at openjdk.org  Thu Oct  2 12:31:46 2025
From: duke at openjdk.org (duke)
Date: Thu, 2 Oct 2025 12:31:46 GMT
Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in shenandoahSTWMark [v2]
In-Reply-To: <TaOBE2ob0qZv5SiR_QAFCuE6i-1tgwEZwaRaEmSkbZI=.c80e8031-213a-4975-a7bf-ca811a54db81@github.com>
References: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
 <TaOBE2ob0qZv5SiR_QAFCuE6i-1tgwEZwaRaEmSkbZI=.c80e8031-213a-4975-a7bf-ca811a54db81@github.com>
Message-ID: <rv8RcBToJ1IoPRGU6B44QjObDoAfbL5i5OOV6G9SKfw=.11c0f7a2-0247-4ae1-a1cb-c93e0f03c094@github.com>

On Thu, 2 Oct 2025 09:31:05 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. 
>> 
>> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`.
>> - `nworkers` is guaranteed to be > 0
>> 
>> Passes `tier1` and `tier2` (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trigger

@fandreuz 
Your change (at version 0801a4965d20cf84b2e4be04c4ab4a98a5e7234c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27589#issuecomment-3360986058

From ayang at openjdk.org  Thu Oct  2 12:32:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Oct 2025 12:32:45 GMT
Subject: RFR: 8369038: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in psParallelCompact
In-Reply-To: <eT9xDOq9N5lTljzrq1Ic7NLh6m_ZEDyRvTzSNYw1xfA=.5686b227-c768-4c85-9e58-0c765be180a4@github.com>
References: <eT9xDOq9N5lTljzrq1Ic7NLh6m_ZEDyRvTzSNYw1xfA=.5686b227-c768-4c85-9e58-0c765be180a4@github.com>
Message-ID: <RCv_NkIytX559QkGpo5MfdZK1urGRM5jLIJq2uDht3E=.63d36493-9082-4039-950f-cbe897116a6b@github.com>

On Thu, 2 Oct 2025 12:23:32 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `MarkFromRootsTask ` to be more precise with what is needed and why.
> 
> - `MarkFromRootsTask` uses `MarkingNMethodClosure` (in `PCAddThreadRootsMarkingTaskClosure`), so we also need `NMethodMarkingScope`.
> - `active_workers ` is guaranteed to be `> 0`
> 
> Passes tier1 and tier2 (fastdebug).

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27607#pullrequestreview-3294368442

From jsikstro at openjdk.org  Thu Oct  2 13:30:02 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 2 Oct 2025 13:30:02 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v3]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <Hx886IwksKMtID6gtJqRVTzzuLNLSnihCbsTII7ydME=.a5477861-fad8-402f-9bb0-b71c1277ad4d@github.com>

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> When looking at this I tried to get my head around the default value of the MaxRAM flag. Since this flag is closely coupled with setting the heap size, I've also gone ahead and removed some of the 32-bit (x86, Windows) code in relation to this flag.
> 
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Namings and comment
 - 8367413: Refactor types in Arguments::set_heap_size()
 - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
 - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp"
   
   This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8.
 - Revert "size_t casts for 32-bit part of test_arguments.cpp"
   
   This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625.
 - size_t casts for 32-bit part of test_arguments.cpp
 - 8367413: Use size_t instead of julong in runtime/arguments.cpp

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

Changes: https://git.openjdk.org/jdk/pull/27224/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=02
  Stats: 92 lines in 4 files changed: 20 ins; 23 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/27224.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224

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

From jsikstro at openjdk.org  Thu Oct  2 13:33:00 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 2 Oct 2025 13:33:00 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v3]
In-Reply-To: <Hx886IwksKMtID6gtJqRVTzzuLNLSnihCbsTII7ydME=.a5477861-fad8-402f-9bb0-b71c1277ad4d@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <Hx886IwksKMtID6gtJqRVTzzuLNLSnihCbsTII7ydME=.a5477861-fad8-402f-9bb0-b71c1277ad4d@github.com>
Message-ID: <T-WDJDkKpQBfMmdSRz-JckuqtnlSsgxY5HuwhvObQfk=.314f34e3-cc18-498f-868d-8a40b27150a8@github.com>

On Thu, 2 Oct 2025 13:30:02 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> When looking at this I tried to get my head around the default value of the MaxRAM flag. Since this flag is closely coupled with setting the heap size, I've also gone ahead and removed some of the 32-bit (x86, Windows) code in relation to this flag.
>> 
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Namings and comment
>  - 8367413: Refactor types in Arguments::set_heap_size()
>  - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
>  - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp"
>    
>    This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8.
>  - Revert "size_t casts for 32-bit part of test_arguments.cpp"
>    
>    This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625.
>  - size_t casts for 32-bit part of test_arguments.cpp
>  - 8367413: Use size_t instead of julong in runtime/arguments.cpp

[JDK-8367485](https://bugs.openjdk.org/browse/JDK-8367485) is now integrated. I've changed the direction of this issue a bit. I now focus on makus sure the transition from uint64_t to size_t is handled robustly along with adding comments to make things easier to understand in `Arguments::set_heap_size()`.

Setting `MaxRAM` to `MIN2(MaxRAM, (uint64_t) ms.ullTotalVirtual)` on Windows was only needed on 32-bit, which is no longer supported. So I've gone ahead and removed it. The virtual address space will practically always be extremely large on Windows 64-bit. See the following resources for more information:
https://learn.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases
https://learn.microsoft.com/en-us/windows-server/get-started/locks-limits?tabs=full-comparison&pivots=windows-server-2025

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

PR Comment: https://git.openjdk.org/jdk/pull/27224#issuecomment-3361236605

From fandreuzzi at openjdk.org  Thu Oct  2 18:52:30 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 2 Oct 2025 18:52:30 GMT
Subject: Integrated: 8368989: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in shenandoahSTWMark
In-Reply-To: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
References: <nHrH11smfWk4fzyXQl9UcGvwQ4Hmz7pyUs8p_Ij2XMk=.d2fa9263-77d3-413a-abb4-82bae6a57642@github.com>
Message-ID: <P7EXBx8Ys_wAljRQEgG4fhBUbIm7ypltcGEn0cXvsow=.2700f4fe-aa84-4d82-8958-24b46c7be7ae@github.com>

On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. 
> 
> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`.
> - `nworkers` is guaranteed to be > 0
> 
> Passes `tier1` and `tier2` (fastdebug).

This pull request has now been integrated.

Changeset: 1d55adee
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d55adee11fc2fdbf2e009e1308b763fd7217dad
Stats:     9 lines in 1 file changed: 5 ins; 2 del; 2 mod

8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark

Reviewed-by: shade, ayang

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

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

From kdnilsen at openjdk.org  Thu Oct  2 23:05:29 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 2 Oct 2025 23:05:29 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v10]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <5T0PXD1oxDN6BXnflm0DFQdBFEfUC95ds21spzVzwMw=.3a538ff0-53da-4397-887d-73ffa98bb9ef@github.com>

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  reviewer feedback to reduce code duplication

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24319/files
  - new: https://git.openjdk.org/jdk/pull/24319/files/cc6f1153..f838b5e1

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

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

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

From kdnilsen at openjdk.org  Thu Oct  2 23:09:50 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 2 Oct 2025 23:09:50 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v9]
In-Reply-To: <nDkv97Tf4j0ailCsZzEU5CE5OCaPOdimeHXVWnva5aQ=.97ad3a84-42dd-46eb-aa31-ce89863c01f3@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com>
 <nDkv97Tf4j0ailCsZzEU5CE5OCaPOdimeHXVWnva5aQ=.97ad3a84-42dd-46eb-aa31-ce89863c01f3@github.com>
Message-ID: <Mb-JTuN01MLD3nvNRMt9QACGN6Ba58kxqrV6j0T53oU=.0589d1ad-ce47-4122-abb9-6da1ffce873f@github.com>

On Tue, 16 Sep 2025 23:15:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation errors after merge
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 91:
> 
>> 89:   }
>> 90: 
>> 91:   // Between consecutive mixed-evacuation cycles, the live data within each candidate region may change due to
> 
> I think we could reduce some duplication and call `recalibrate_old_collection_candidates_live_memory` here if the function didn't have the side effect of updating `_live_bytes_in_unprocessed_candidates`. Perhaps the function could return `total_live_data` and be `const`?

Good suggestion.  I've refactored a little.  I think it can't be const because we sort the _region_data.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2400354971

From wkemper at openjdk.org  Thu Oct  2 23:16:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 2 Oct 2025 23:16:50 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v12]
In-Reply-To: <zykF_uZbCnQ24lXQ7WDVnnbofQqtZbm3THblcpqnUnc=.c22227ea-3a1b-4507-b4f1-b48368c80fa3@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <zykF_uZbCnQ24lXQ7WDVnnbofQqtZbm3THblcpqnUnc=.c22227ea-3a1b-4507-b4f1-b48368c80fa3@github.com>
Message-ID: <ln2G4t7R7LLurFDBeSHLzY4-bWw0D0oCVXsOeGegHUQ=.75155da3-905c-465e-bad1-a3c54fba9b0b@github.com>

On Tue, 30 Sep 2025 21:55:46 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
>> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
>> 
>> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
>> 
>> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.
>
> Kelvin Nilsen has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - small refactoring
>  - OO refinements to used_regions_size()
>  - fix broken assert from previous commit
>  - OO refinements to free_unaffiliated_regions()
>  - OO refinements to max_capacity()

A few comment from our review session. Will post more later.

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

> 951: }
> 952: 
> 953: size_t ShenandoahGeneration::max_capacity() const {

We never instantiate `ShenandoahGeneration` even non-generational mode gets `ShenandoahGlobalGeneration`. You could make these methods pure virtual. The implementation here should never be called.

src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp line 40:

> 38: 
> 39: size_t ShenandoahGlobalGeneration::max_capacity() const {
> 40: #ifdef ASSERT

Could we just have this assertion one time in the constructor?

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26867#pullrequestreview-3217907983
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400363917
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400358514

From wkemper at openjdk.org  Thu Oct  2 23:16:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 2 Oct 2025 23:16:55 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
Message-ID: <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>

On Tue, 9 Sep 2025 22:07:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
>> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
>> 
>> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
>> 
>> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another tweak to make GHA gtest happy

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

> 53: class ShenandoahLeftRightIterator {
> 54: private:
> 55:   index_type _idx;

Changing this to a different type introduces a lot of noise in the review. It was compiling before this change, can we figure out if it is really necessary to change this type?

src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 134:

> 132:   virtual size_t used_regions_size() const;
> 133:   virtual size_t free_unaffiliated_regions() const;
> 134:   size_t used() const override {

This is already virtual (since it is marked as `override`) so it makes sense to put these different behaviors in the different generation subclasses.

src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 154:

> 152:   size_t available() const override;
> 153:   size_t available_with_reserve() const;
> 154:   size_t used_including_humongous_waste() const {

Can we get rid of this method? Just have callers call `used` now?

src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 253:

> 251:     if (available_in_region < plab_min_size_in_bytes) {
> 252:       // The available memory in young had been retired.  Retire it in old also.
> 253:       region_to_be_used_in_old += available_in_region;

This looks like a dead store.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 104:

> 102: 
> 103:   // Use this only for unit testing.  Do not use for production.
> 104:   inline void set_capacity(size_t bytes) {

We should be able to inline this code in `test_shenandoahOldHeuristic.cpp` in the constructor of the test fixture that calls this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2344980222
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2344937348
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2344940289
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345035769
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345072351

From wkemper at openjdk.org  Fri Oct  3 00:03:58 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 3 Oct 2025 00:03:58 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v12]
In-Reply-To: <zykF_uZbCnQ24lXQ7WDVnnbofQqtZbm3THblcpqnUnc=.c22227ea-3a1b-4507-b4f1-b48368c80fa3@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <zykF_uZbCnQ24lXQ7WDVnnbofQqtZbm3THblcpqnUnc=.c22227ea-3a1b-4507-b4f1-b48368c80fa3@github.com>
Message-ID: <nSBP3szWwdm3T_aArPlKNtT1gnGZ0XOBBTiVYQGDxX4=.3b89009d-bc68-435d-b690-fab6711b3866@github.com>

On Tue, 30 Sep 2025 21:55:46 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
>> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
>> 
>> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
>> 
>> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.
>
> Kelvin Nilsen has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - small refactoring
>  - OO refinements to used_regions_size()
>  - fix broken assert from previous commit
>  - OO refinements to free_unaffiliated_regions()
>  - OO refinements to max_capacity()

Mostly nits and questions.

src/hotspot/share/gc/shared/gc_globals.hpp line 472:

> 470:   product(size_t, SoftMaxHeapSize, 0, MANAGEABLE,                           \
> 471:           "Soft limit for maximum heap size (in bytes)")                    \
> 472:           constraint(SoftMaxHeapSizeConstraintFunc,AfterMemoryInit)         \

Changing a common file might raise eyebrows. Why do we need this?

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

> 1151: void ShenandoahConcurrentGC::op_final_update_refs() {
> 1152:   ShenandoahHeap* const heap = ShenandoahHeap::heap();
> 1153:   bool is_generational = heap->mode()->is_generational();

Are the changes here necessary? This is a big PR, it would be helpful to minimize unnecessary changes.

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1145:

> 1143:   _preserved_marks->reclaim();
> 1144: 
> 1145:   // We defer generation resizing actions until after cset regions have been recycled.  We do this even following an

Stale comment?

src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.hpp line 1:

> 1: /*

Is there any point in keeping this file now? Not sure what this class is doing now.

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

> 743: //  2. Region's free is less than minimum TLAB size and is retired
> 744: //  3. The unused portion of memory in the last region of a humongous object
> 745: void ShenandoahHeap::increase_used(const ShenandoahAllocRequest& req) {

I don't see the point of this method now. Can we delete it?

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

> 2717:   assert(used() <= ShenandoahHeap::heap()->max_capacity(), "sanity");
> 2718:   assert(committed() <= ShenandoahHeap::heap()->max_capacity(), "sanity");
> 2719:   assert(max_capacity() <= ShenandoahHeap::heap()->max_capacity(), "sanity");

This last one is just comparing the results of the same method call. Are we worried about races here?

src/hotspot/share/gc/shenandoah/shenandoahMemoryPool.cpp line 65:

> 63:   // to make sense under the race. See JDK-8207200.
> 64:   committed = MAX2(used, committed);
> 65:   assert(used <= committed, "used: %zu, committed: %zu", used, committed);

Shouldn't it always be the case that `initial <= used <= committed <= max`?

src/hotspot/share/gc/shenandoah/shenandoahSimpleBitMap.cpp line 42:

> 40: }
> 41: 
> 42: size_t ShenandoahSimpleBitMap::count_leading_ones(index_type start_idx) const {

Did we figure out why we want to rename this type? It adds a lot of noise to this PR and I'd hate to do something like this because of a C++ technicality.

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 498:

> 496: 
> 497: class ShenandoahVerifyHeapRegionClosure : public ShenandoahHeapRegionClosure {
> 498:   private:

Formatting the access modifiers like this looks idiosyncratic:

% grep -ri -P '^  private:' src/hotspot | wc -l                  
115
% grep -ri -P '^private:' src/hotspot | wc -l  
1444

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26867#pullrequestreview-3296845640
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400422999
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400380773
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400382789
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400397766
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400401051
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400404948
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400410359
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400411950
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400418474

From wkemper at openjdk.org  Fri Oct  3 00:04:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 3 Oct 2025 00:04:00 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>
Message-ID: <Ylnv8et_CBLD5a1k2sZ5pvFrsf5UvavJDs3wdQx4dow=.3d4dfec9-618e-4344-ab93-8051eb96c4db@github.com>

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

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another tweak to make GHA gtest happy
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 253:
> 
>> 251:     if (available_in_region < plab_min_size_in_bytes) {
>> 252:       // The available memory in young had been retired.  Retire it in old also.
>> 253:       region_to_be_used_in_old += available_in_region;
> 
> This looks like a dead store.

This chunk of code from 253-258 looks like it could be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400392332

From kdnilsen at openjdk.org  Fri Oct  3 00:21:11 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 00:21:11 GMT
Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v2]
In-Reply-To: <JTwkqXthnFpzrfVsFosxLf2uDWRBXWguvioNPr-XqWA=.41881654-4539-4920-9d65-e93b210913f6@github.com>
References: <JTwkqXthnFpzrfVsFosxLf2uDWRBXWguvioNPr-XqWA=.41881654-4539-4920-9d65-e93b210913f6@github.com>
Message-ID: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com>

> When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card.  The existing code is not reliable following class unloading.
> 
> The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region.  Above TAMS, all objects are presumed live and parsable.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  fix idiosyncratic formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27353/files
  - new: https://git.openjdk.org/jdk/pull/27353/files/76979421..668e8615

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

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

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

From kdnilsen at openjdk.org  Fri Oct  3 00:25:45 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 00:25:45 GMT
Subject: RFR: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate [v2]
In-Reply-To: <DVRNqsAD6wijI3vBK8Gpb1oZzjlwecFlizYUpSq84tI=.d66f5b08-98eb-4946-a5b1-1d80d0860b0b@github.com>
References: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
 <DVRNqsAD6wijI3vBK8Gpb1oZzjlwecFlizYUpSq84tI=.d66f5b08-98eb-4946-a5b1-1d80d0860b0b@github.com>
Message-ID: <7OWJnIPeKppSXqKzNJvrqD0vKHOZZzKpLNe--W9CS5Q=.f367368e-e209-4c48-831d-65c080426d1c@github.com>

On Thu, 25 Sep 2025 23:45:38 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix several typos
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 52:
> 
>> 50:   // The sampled allocation rate is computed from (allocated - _last_sample_value) / (current_time - _last_sample_time).
>> 51:   // Return the newly computed rate if the sample is taken, zero if it is not an appropriate time to add a sample.
>> 52:   // In the case that a new sample is not take, overwrite unaccounted_bytes_allocated with bytes allocated since
> 
> s/take/taken

Fixed.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2400443230

From xpeng at openjdk.org  Fri Oct  3 00:33:46 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 3 Oct 2025 00:33:46 GMT
Subject: RFR: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate [v2]
In-Reply-To: <GkWjWcWY8Ovl9DIitUg2ivSxP2a9cZchgGEq1WVmsuE=.aa4fa2e3-81e8-403a-a1e8-f71c2b609119@github.com>
References: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
 <GkWjWcWY8Ovl9DIitUg2ivSxP2a9cZchgGEq1WVmsuE=.aa4fa2e3-81e8-403a-a1e8-f71c2b609119@github.com>
Message-ID: <kAFtiqLXdAvTsB-WXMIDERZN7gXPsMqzdouv3AdJwWQ=.fb9d7856-10c6-4578-b031-08f1841236bc@github.com>

On Sat, 27 Sep 2025 23:13:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Add documentation to ShenandoahAllocationRate
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix several typos

Looks good to me, thanks!

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

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27505#pullrequestreview-3296939226

From wkemper at openjdk.org  Fri Oct  3 00:37:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 3 Oct 2025 00:37:55 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v10]
In-Reply-To: <5T0PXD1oxDN6BXnflm0DFQdBFEfUC95ds21spzVzwMw=.3a538ff0-53da-4397-887d-73ffa98bb9ef@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <5T0PXD1oxDN6BXnflm0DFQdBFEfUC95ds21spzVzwMw=.3a538ff0-53da-4397-887d-73ffa98bb9ef@github.com>
Message-ID: <akgtB62VhcaXBRFTuiFdojUbwTIrRBbPMDB4XKt_S4c=.bcdd99a7-9f35-4a09-9cac-65fe9b466f18@github.com>

On Thu, 2 Oct 2025 23:05:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
>> 
>> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
>> 
>> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviewer feedback to reduce code duplication

I think we can delete the field `_mixed_candidate_garbage_words` now with the refactoring. Would also be good to run this through testing again.

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 262:

> 260:   volatile size_t _critical_pins;
> 261: 
> 262:   size_t _mixed_candidate_garbage_words;

Can we delete this field now?

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24319#pullrequestreview-3296942280
PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2400454938

From aboldtch at openjdk.org  Fri Oct  3 08:17:31 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 3 Oct 2025 08:17:31 GMT
Subject: RFR: 8367317: ZGC:
 ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow [v3]
In-Reply-To: <MrtRg-MtrMA5rRk0qu4Jd2tTJuMdEVi43XeQF05jUtI=.6ebb93f7-39d1-4f13-aaff-db62d99a0846@github.com>
References: <MrtRg-MtrMA5rRk0qu4Jd2tTJuMdEVi43XeQF05jUtI=.6ebb93f7-39d1-4f13-aaff-db62d99a0846@github.com>
Message-ID: <tRDgjTEh2aYpGa950hinUBL-B3Rwzz9Ns6jberBpMBc=.dd74f5da-1144-4d79-96b3-3c1275eda549@github.com>

> ZVirtualMemoryReserver::force_reserve_discontiguous is a debug only API used to simulate and test a discontinuous heap. The loop variable `end` is incorrectly checked which may lead to an underflow.
> 
> In our normal testing we never observe this as the address space is always available. We observed this issue when running a hardened build (like ASAN) which had already mmapped the address space we tried to reserve.
> 
> Rather than always jump two reserve sizes in its search, it searches every reserve size, moving an extra reserve size every time it succeeds with a reservation (so that there always is a gap).  Searching in reserve sized steps is not really a requirement here, we could have just used a granule sized step.

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

 - Merge tag 'jdk-26+18' into JDK-8367317
   
   Added tag jdk-26+18 for changeset 5251405c
 - Merge tag 'jdk-26+17' into JDK-8367317
   
   Added tag jdk-26+17 for changeset 2aafda19
 - 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27207/files
  - new: https://git.openjdk.org/jdk/pull/27207/files/6c77150f..0068e956

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

  Stats: 11978 lines in 389 files changed: 6399 ins; 3203 del; 2376 mod
  Patch: https://git.openjdk.org/jdk/pull/27207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27207/head:pull/27207

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

From aboldtch at openjdk.org  Fri Oct  3 08:17:55 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 3 Oct 2025 08:17:55 GMT
Subject: RFR: 8351137: ZGC: Improve ZValueStorage alignment support [v4]
In-Reply-To: <GNS93cR60yXhAg3e7xq700RXmu-pYa6muIwmfJIBrac=.f1991bdf-d6fc-4255-8f04-c5717455baa6@github.com>
References: <GNS93cR60yXhAg3e7xq700RXmu-pYa6muIwmfJIBrac=.f1991bdf-d6fc-4255-8f04-c5717455baa6@github.com>
Message-ID: <cQxaExm6TJQRCaYqeYTsFxhpnxsGXs7RcptTHMCyEww=.947637fc-8e9d-4b31-94c3-8e72bf7f222a@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 four additional commits since the last revision:

 - 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/857249f5..989be624

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

  Stats: 11978 lines in 389 files changed: 6399 ins; 3203 del; 2376 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 ayang at openjdk.org  Fri Oct  3 08:38:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Oct 2025 08:38:58 GMT
Subject: RFR: 8369097: Parallel: Support allocation in from space when heap is
 too full
Message-ID: <uEZ5wcprvd6EY5dh9ZI52Br4ybO9L3Z5CkldaEuh2wE=.b9e07a4d-c62e-473d-b502-d831cb2a5b7a@github.com>

Support allocation in from-space of young-gen in extreme cases (heap is almost full), so that gc-log shows used-heap is almost at max-heap when OOM is thrown.

Test: tier1-5

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

Commit messages:
 - pgc-allocate-in-from-space

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

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

From duke at openjdk.org  Fri Oct  3 10:45:46 2025
From: duke at openjdk.org (duke)
Date: Fri, 3 Oct 2025 10:45:46 GMT
Subject: RFR: 8369038: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in psParallelCompact
In-Reply-To: <eT9xDOq9N5lTljzrq1Ic7NLh6m_ZEDyRvTzSNYw1xfA=.5686b227-c768-4c85-9e58-0c765be180a4@github.com>
References: <eT9xDOq9N5lTljzrq1Ic7NLh6m_ZEDyRvTzSNYw1xfA=.5686b227-c768-4c85-9e58-0c765be180a4@github.com>
Message-ID: <IuyAq1417YDi9A4ZHiAbrXHQM8Yvt8onAoB-quCyBaQ=.4384c078-d291-481d-9d4a-f1491750acff@github.com>

On Thu, 2 Oct 2025 12:23:32 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `MarkFromRootsTask ` to be more precise with what is needed and why.
> 
> - `MarkFromRootsTask` uses `MarkingNMethodClosure` (in `PCAddThreadRootsMarkingTaskClosure`), so we also need `NMethodMarkingScope`.
> - `active_workers ` is guaranteed to be `> 0`
> 
> Passes tier1 and tier2 (fastdebug).

@fandreuz 
Your change (at version 1ab02decd10923287786ec8ce018db4b45ab0f3e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27607#issuecomment-3365222423

From ayang at openjdk.org  Fri Oct  3 14:13:27 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Oct 2025 14:13:27 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v8]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <cnK3OQz5KWqelrUFUbTLtHEs_zcxH7iKmf4BvluYyLY=.c0a18b7c-bc15-42da-9703-96921bd4b5d5@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

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/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/2ccd0dd6..3227621e

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

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

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

From jsikstro at openjdk.org  Fri Oct  3 14:33:10 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 3 Oct 2025 14:33:10 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v6]
In-Reply-To: <TydqjZ-401J-3RByzvnMJz8zqHPWLfGjx7GeZddD15E=.a178114b-8423-4c60-8833-3ba04de7e9a4@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
 <8eWze_-jDaiR6YqPIXO69uHyMLQUSG_0wM3jyTmYYN4=.bf449c42-7659-498f-b7f3-c8f3073b36d5@github.com>
 <TydqjZ-401J-3RByzvnMJz8zqHPWLfGjx7GeZddD15E=.a178114b-8423-4c60-8833-3ba04de7e9a4@github.com>
Message-ID: <BSA9TeBOYmwOZ2ma-qPc8ubortjQaBPjeEFhEWUaNug=.6fdcb78a-edf4-424b-a664-00c36b01226c@github.com>

On Thu, 2 Oct 2025 09:52:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelArguments.cpp line 131:
>> 
>>> 129:   if (page_sz == os::vm_page_size()) {
>>> 130:     log_warning(gc, heap)("MinHeapSize (%zu) must be large enough for 4 * page-size; Disabling UseLargePages for heap", MinHeapSize);
>>> 131:     return;
>> 
>> Wouldn't it make sense to do `FLAG_SET_ERGO(UseLargepages, false)` here since it is effectively disabled.
>
> There are non-heap uses of `UseLargePages` as well. Here we concluded heap can't use large-page, but other systems still can.

I see, thank you.

>> src/hotspot/share/gc/parallel/parallelArguments.cpp line 137:
>> 
>>> 135:   assert(is_power_of_2((intptr_t)page_sz), "must be a power of 2");
>>> 136:   // Space is largepage-aligned.
>>> 137:   size_t new_alignment = page_sz;
>> 
>> To me it looks like new_alignment will always be different from SpaceAlignment here. We could simplify this to the following:
>> 
>> 
>>   SpaceAlignment = page_sz;
>>     
>>   // Redo everything from the start
>>   initialize_heap_flags_and_sizes_one_pass();
>
>> To me it looks like new_alignment will always be different from SpaceAlignment here. 
> 
> Why so? (I know the default value of SpaceAlignment is 64K*8 bytes, which is not a common large-page-size, but that info is not directly accessible in this context.)

We discussed this offline, but if `default_space_alignment()` ever coincided with a Large page size, say 2MB, and 2MB large pages are chosen, SpaceAlignment would still be equal to `default_space_alignment()` and we would end up reserving small pages in `ParallelScavengeHeap::initialize()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2402168281
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2402167659

From ayang at openjdk.org  Fri Oct  3 14:44:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Oct 2025 14:44:15 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v9]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <T6RXJdnu8g2qYttfO-U5dClh6O9y-c1kT67kTRF7Nis=.6d5a6f48-1f97-4295-adf1-201d1565e916@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

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/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/3227621e..421f1c4d

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

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

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

From kdnilsen at openjdk.org  Fri Oct  3 18:41:52 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 18:41:52 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>
Message-ID: <17APPI-yLZ70C8-EIxK8Olf3iu8mtA5FLB-338EYtV8=.996629b7-0001-4195-8f7f-01dfe4130d91@github.com>

On Fri, 12 Sep 2025 17:04:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another tweak to make GHA gtest happy
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 134:
> 
>> 132:   virtual size_t used_regions_size() const;
>> 133:   virtual size_t free_unaffiliated_regions() const;
>> 134:   size_t used() const override {
> 
> This is already virtual (since it is marked as `override`) so it makes sense to put these different behaviors in the different generation subclasses.

Thanks.  This is done now.

> src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 154:
> 
>> 152:   size_t available() const override;
>> 153:   size_t available_with_reserve() const;
>> 154:   size_t used_including_humongous_waste() const {
> 
> Can we get rid of this method? Just have callers call `used` now?

Correct.  It has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2402976401
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2402978481

From kdnilsen at openjdk.org  Fri Oct  3 19:49:41 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 19:49:41 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v13]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <VUY9IlfSX5L0IVsRxI99yGCPBEJzPKpAqU4OkYEqa1o=.7d139afa-fc58-4d19-929a-1ad5bb264cf4@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  revert introduction of index_type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/43e1358f..f4dadd43

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

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

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

From kdnilsen at openjdk.org  Fri Oct  3 19:49:44 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 19:49:44 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>
Message-ID: <fwM8u3IRUnHngzbIifoX63aME__0C8xN3GpfEPjHuqE=.561eb09b-c4ea-4007-9c07-6b8e592c1b44@github.com>

On Fri, 12 Sep 2025 17:19:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another tweak to make GHA gtest happy
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 55:
> 
>> 53: class ShenandoahLeftRightIterator {
>> 54: private:
>> 55:   index_type _idx;
> 
> Changing this to a different type introduces a lot of noise in the review. It was compiling before this change, can we figure out if it is really necessary to change this type?

Thanks for insisting on highest standards.  I think I've figured out how to resolve the conflicts with multiple definitions of idx_t and committed a change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2403182952

From kdnilsen at openjdk.org  Fri Oct  3 20:09:30 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 20:09:30 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v14]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <ow6Nd42Z36Qmu32f4wV67tJWjEHAT296eTExYs83VMw=.5066c6b9-882d-4ec4-a2ac-b1c661965ebd@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  simplify implementation of promote_in_place

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/f4dadd43..f6a1182e

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

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

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

From kdnilsen at openjdk.org  Fri Oct  3 20:31:12 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 20:31:12 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v10]
In-Reply-To: <akgtB62VhcaXBRFTuiFdojUbwTIrRBbPMDB4XKt_S4c=.bcdd99a7-9f35-4a09-9cac-65fe9b466f18@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <5T0PXD1oxDN6BXnflm0DFQdBFEfUC95ds21spzVzwMw=.3a538ff0-53da-4397-887d-73ffa98bb9ef@github.com>
 <akgtB62VhcaXBRFTuiFdojUbwTIrRBbPMDB4XKt_S4c=.bcdd99a7-9f35-4a09-9cac-65fe9b466f18@github.com>
Message-ID: <u5fgiO32uqIZDXyqWhr9WdZdXTwLVX2y6XXepKlVJ7o=.9cf85aaa-f053-46ea-a7d5-934e0add99ec@github.com>

On Fri, 3 Oct 2025 00:34:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviewer feedback to reduce code duplication
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 262:
> 
>> 260:   volatile size_t _critical_pins;
>> 261: 
>> 262:   size_t _mixed_candidate_garbage_words;
> 
> Can we delete this field now?

Good catch.  Removed.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2403271191

From kdnilsen at openjdk.org  Fri Oct  3 20:31:10 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 20:31:10 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v11]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <LIVPXlhFN7oH4r0kpA8qSdNJ55M-kHKb9Anq12FMZWs=.e653d897-4d8b-4a0e-995e-6eb61f503bd4@github.com>

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  remove _mixed_candidate_garbage_words from ShenandoahHeapRegion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24319/files
  - new: https://git.openjdk.org/jdk/pull/24319/files/f838b5e1..4e920417

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

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

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

From kdnilsen at openjdk.org  Fri Oct  3 20:53:48 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 20:53:48 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v11]
In-Reply-To: <LIVPXlhFN7oH4r0kpA8qSdNJ55M-kHKb9Anq12FMZWs=.e653d897-4d8b-4a0e-995e-6eb61f503bd4@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <LIVPXlhFN7oH4r0kpA8qSdNJ55M-kHKb9Anq12FMZWs=.e653d897-4d8b-4a0e-995e-6eb61f503bd4@github.com>
Message-ID: <l4RffP7WVQmKGfUkOkjZKPKRO-KFIbQOglPS6uyQbJY=.f5792180-dc4b-451c-be6f-6f3f2fc5bd63@github.com>

On Fri, 3 Oct 2025 20:31:10 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
>> 
>> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
>> 
>> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove _mixed_candidate_garbage_words from ShenandoahHeapRegion

Retesting through internal CI pipeline

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

PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3367185418

From kdnilsen at openjdk.org  Fri Oct  3 20:53:50 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 20:53:50 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v10]
In-Reply-To: <u5fgiO32uqIZDXyqWhr9WdZdXTwLVX2y6XXepKlVJ7o=.9cf85aaa-f053-46ea-a7d5-934e0add99ec@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <5T0PXD1oxDN6BXnflm0DFQdBFEfUC95ds21spzVzwMw=.3a538ff0-53da-4397-887d-73ffa98bb9ef@github.com>
 <akgtB62VhcaXBRFTuiFdojUbwTIrRBbPMDB4XKt_S4c=.bcdd99a7-9f35-4a09-9cac-65fe9b466f18@github.com>
 <u5fgiO32uqIZDXyqWhr9WdZdXTwLVX2y6XXepKlVJ7o=.9cf85aaa-f053-46ea-a7d5-934e0add99ec@github.com>
Message-ID: <_Bh5NmZkINYluZJrPU4CmqttX3tl5oMy49WCjoJD_sw=.abe539ff-f71b-4360-b157-e14853d26b72@github.com>

On Fri, 3 Oct 2025 20:27:26 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 262:
>> 
>>> 260:   volatile size_t _critical_pins;
>>> 261: 
>>> 262:   size_t _mixed_candidate_garbage_words;
>> 
>> Can we delete this field now?
>
> Good catch.  Removed.  Thanks.

Done.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2403313761

From dcubed at openjdk.org  Fri Oct  3 21:05:16 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 21:05:16 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
Message-ID: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>

In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:

[JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs

[JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC

[JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

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

Commit messages:
 - 8369133: Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option
 - 8369132 disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
 - 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs

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

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

From ayang at openjdk.org  Fri Oct  3 21:05:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Oct 2025 21:05:17 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
Message-ID: <63cMLQaAuITwPnfrDch2UblWoWXcKu1pwJk54-ehVXA=.feee83fd-1d9b-47dd-8a3e-fd6b98f3f3e0@github.com>

On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
> 
> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
> 
> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
> 
> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27629#pullrequestreview-3300900845

From dcubed at openjdk.org  Fri Oct  3 21:05:19 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 21:05:19 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <63cMLQaAuITwPnfrDch2UblWoWXcKu1pwJk54-ehVXA=.feee83fd-1d9b-47dd-8a3e-fd6b98f3f3e0@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
 <63cMLQaAuITwPnfrDch2UblWoWXcKu1pwJk54-ehVXA=.feee83fd-1d9b-47dd-8a3e-fd6b98f3f3e0@github.com>
Message-ID: <_a422YA5GgS6goxf5CnnaG-YsMmfn-M6vYqkK0XYnR4=.21894e92-f2f6-4d93-8fd7-3cfa0447f7c8@github.com>

On Fri, 3 Oct 2025 20:47:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
>> 
>> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
>> 
>> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
>> 
>> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk - Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367206699

From dcubed at openjdk.org  Fri Oct  3 21:05:18 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 21:05:18 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
Message-ID: <mgOLvnR1MQjGI9_8EnNU5geiJw_R6G2d_JX5n7n19kc=.e0c75b93-abd6-4d72-a3b6-fe257741e19a@github.com>

On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
> 
> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
> 
> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
> 
> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

Blasted auto-correct keeps changing what I type...

It's been too long since I've bundled multiple fixes together. I forgot a couple of steps...

All Mach5 testing that I've done is documented in each bug report.

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

PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367198386
PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367205612
PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367207761

From dholmes at openjdk.org  Fri Oct  3 21:14:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Oct 2025 21:14:58 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
Message-ID: <vTz-Ajc6zR7Sc5dLXlXoH584Qy-NWb2Jzca0ETM5Lwc=.2f04a3d1-a4fa-4024-ba30-b11af63c965b@github.com>

On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
> 
> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
> 
> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
> 
> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

Seems reasonable.

I approved the fix for jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java   a couple of days ago but for some reason the author has not been around to integrate it. I have made a note on the PR that now they will need to fix the PL too.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27629#pullrequestreview-3300964363

From dcubed at openjdk.org  Fri Oct  3 21:14:59 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 21:14:59 GMT
Subject: Integrated: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
Message-ID: <xcMGbupgO3JhcE9laWQzZTCnPkLmBw3z0euW1ehBKEo=.dd8b00a5-d232-449e-9b2b-d35d23d5678e@github.com>

On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
> 
> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
> 
> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
> 
> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

This pull request has now been integrated.

Changeset: 837f634b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/837f634bf29fd877dd62a2e0f7d7a1bd383372d3
Stats:     4 lines in 4 files changed: 4 ins; 0 del; 0 mod

8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
8369132: Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
8369133: Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

Reviewed-by: ayang, dholmes

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

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

From kdnilsen at openjdk.org  Fri Oct  3 22:07:53 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 22:07:53 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v14]
In-Reply-To: <ow6Nd42Z36Qmu32f4wV67tJWjEHAT296eTExYs83VMw=.5066c6b9-882d-4ec4-a2ac-b1c661965ebd@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <ow6Nd42Z36Qmu32f4wV67tJWjEHAT296eTExYs83VMw=.5066c6b9-882d-4ec4-a2ac-b1c661965ebd@github.com>
Message-ID: <j80QwLMBFP9sHusg37FaUpTaR-rBKPL8yAeDpzJbVD4=.b4eb3185-eeb2-4a5b-921a-d8a03fdf507b@github.com>

On Fri, 3 Oct 2025 20:09:30 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
>> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
>> 
>> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
>> 
>> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify implementation of promote_in_place

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 136:

> 134: 
> 135: #ifndef PRODUCT
> 136:   void dump_bitmap_row(idx_t region_idx) const;

maybe revert this.  bitmap rows are not idx_t.

src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 71:

> 69:   // Usage
> 70: 
> 71:   volatile size_t _used;

Get rid of this.  no longer needed.  (search for volatile, most should go.)

do we need _max_capacity?  probably not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2403455453
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2403449921

From kdnilsen at openjdk.org  Fri Oct  3 22:07:55 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Oct 2025 22:07:55 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <Ylnv8et_CBLD5a1k2sZ5pvFrsf5UvavJDs3wdQx4dow=.3d4dfec9-618e-4344-ab93-8051eb96c4db@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>
 <Ylnv8et_CBLD5a1k2sZ5pvFrsf5UvavJDs3wdQx4dow=.3d4dfec9-618e-4344-ab93-8051eb96c4db@github.com>
Message-ID: <rt6FOoKuijodivm10Sz8gayaE7dy8GJMI8kgpv6qMbc=.f7102437-7bd4-4eb4-9dd4-1eff0932e481@github.com>

On Thu, 2 Oct 2025 23:31:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 253:
>> 
>>> 251:     if (available_in_region < plab_min_size_in_bytes) {
>>> 252:       // The available memory in young had been retired.  Retire it in old also.
>>> 253:       region_to_be_used_in_old += available_in_region;
>> 
>> This looks like a dead store.
>
> This chunk of code from 253-258 looks like it could be removed.

You're right.  We can simplify this.  Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2403216907

From dcubed at openjdk.org  Fri Oct  3 22:15:55 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 22:15:55 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <vTz-Ajc6zR7Sc5dLXlXoH584Qy-NWb2Jzca0ETM5Lwc=.2f04a3d1-a4fa-4024-ba30-b11af63c965b@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
 <vTz-Ajc6zR7Sc5dLXlXoH584Qy-NWb2Jzca0ETM5Lwc=.2f04a3d1-a4fa-4024-ba30-b11af63c965b@github.com>
Message-ID: <0aO_PY7lyXtH0jQ2_Zhk7QYFdDtZjYFr_-oluOpdF8k=.e7659811-f5a6-40a9-a4e6-7e2357cc77ac@github.com>

On Fri, 3 Oct 2025 21:10:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
>> 
>> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
>> 
>> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
>> 
>> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option
>
> Seems reasonable.
> 
> I approved the fix for jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java   a couple of days ago but for some reason the author has not been around to integrate it. I have made a note on the PR that now they will need to fix the PL too.
> 
> Thanks

@dholmes-ora - Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367369658

From wkemper at openjdk.org  Fri Oct  3 23:26:05 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 3 Oct 2025 23:26:05 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size
 budgeting
Message-ID: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@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%)

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

Commit messages:
 - Little cleanup
 - Fix wrong asserts
 - Only use old generation in generational mode
 - More accurate method names for cset fields, consider promotion reserves when computing excess old regions
 - Merge fallout
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Tweak comment
 - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option
 - Merge remote-tracking branch 'earthling-jdk/adaptive-tenuring-threshold' into make-evac-tracking-runtime-option
 - ... and 42 more: https://git.openjdk.org/jdk/compare/648582ab...fd9619dd

Changes: https://git.openjdk.org/jdk/pull/27632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314599
  Stats: 292 lines in 16 files changed: 145 ins; 72 del; 75 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 wkemper at openjdk.org  Fri Oct  3 23:35:48 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 3 Oct 2025 23:35:48 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v11]
In-Reply-To: <LIVPXlhFN7oH4r0kpA8qSdNJ55M-kHKb9Anq12FMZWs=.e653d897-4d8b-4a0e-995e-6eb61f503bd4@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <LIVPXlhFN7oH4r0kpA8qSdNJ55M-kHKb9Anq12FMZWs=.e653d897-4d8b-4a0e-995e-6eb61f503bd4@github.com>
Message-ID: <It2AF93C9PLwaIXOwn-4FttAcgr8zXNBA7mi7tlpK7Y=.5d50e0d0-9e1e-4bfe-9b73-e5843668ea60@github.com>

On Fri, 3 Oct 2025 20:31:10 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
>> 
>> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
>> 
>> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove _mixed_candidate_garbage_words from ShenandoahHeapRegion

Code looks good to me. Let's double check performance results (especially for non-generational mode).

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24319#pullrequestreview-3301312685

From shade at openjdk.org  Mon Oct  6 07:18:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 07:18:51 GMT
Subject: RFR: 8369041: Release memory after testing in ThreadsRunner.java
In-Reply-To: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>
References: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>
Message-ID: <4B4zrhNT8ahkpA16uw09zfVTxphu6IYNxLq4gT4JLa8=.71d7f840-2108-485a-9255-cb4f3afe848e@github.com>

On Thu, 2 Oct 2025 11:16:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Small patch of cleaning up no longer used data structures after testing is complete. 
> 
> Test: tier1-5

Feels like these cleanup calls belong in `finally` block, so that they get cleaned up even on exception?

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

PR Review: https://git.openjdk.org/jdk/pull/27606#pullrequestreview-3303123306

From shade at openjdk.org  Mon Oct  6 07:48:02 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 07:48:02 GMT
Subject: RFR: 8369038: Parallel: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in psParallelCompact
In-Reply-To: <eT9xDOq9N5lTljzrq1Ic7NLh6m_ZEDyRvTzSNYw1xfA=.5686b227-c768-4c85-9e58-0c765be180a4@github.com>
References: <eT9xDOq9N5lTljzrq1Ic7NLh6m_ZEDyRvTzSNYw1xfA=.5686b227-c768-4c85-9e58-0c765be180a4@github.com>
Message-ID: <HqKA1nHGKfGtEHGyH4hKYfRhxY4khruFwQujagb9sWA=.1087b54c-dc0d-4823-8534-24255b865bcd@github.com>

On Thu, 2 Oct 2025 12:23:32 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `MarkFromRootsTask ` to be more precise with what is needed and why.
> 
> - `MarkFromRootsTask` uses `MarkingNMethodClosure` (in `PCAddThreadRootsMarkingTaskClosure`), so we also need `NMethodMarkingScope`.
> - `active_workers ` is guaranteed to be `> 0`
> 
> Passes tier1 and tier2 (fastdebug).

Looks similar to what we did for other collectors.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27607#pullrequestreview-3303216535

From fandreuzzi at openjdk.org  Mon Oct  6 08:17:57 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 6 Oct 2025 08:17:57 GMT
Subject: Integrated: 8369038: Parallel: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in psParallelCompact
In-Reply-To: <eT9xDOq9N5lTljzrq1Ic7NLh6m_ZEDyRvTzSNYw1xfA=.5686b227-c768-4c85-9e58-0c765be180a4@github.com>
References: <eT9xDOq9N5lTljzrq1Ic7NLh6m_ZEDyRvTzSNYw1xfA=.5686b227-c768-4c85-9e58-0c765be180a4@github.com>
Message-ID: <PWA2MfQpL5h-kh6oUHNfyhjC8a-LJAEwjK8p9Ptv66w=.ffc2e54f-aa5f-4a62-b3c0-06f03e9e118c@github.com>

On Thu, 2 Oct 2025 12:23:32 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `MarkFromRootsTask ` to be more precise with what is needed and why.
> 
> - `MarkFromRootsTask` uses `MarkingNMethodClosure` (in `PCAddThreadRootsMarkingTaskClosure`), so we also need `NMethodMarkingScope`.
> - `active_workers ` is guaranteed to be `> 0`
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: baf8bc57
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/baf8bc5701c43425e3345f82d4318b134b26d7c9
Stats:     6 lines in 1 file changed: 3 ins; 1 del; 2 mod

8369038: Parallel: Use NMethodMarkingScope and ThreadsClaimTokenScope in psParallelCompact

Reviewed-by: ayang, shade

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

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

From ayang at openjdk.org  Mon Oct  6 10:03:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 Oct 2025 10:03:10 GMT
Subject: RFR: 8369041: Release memory after testing in ThreadsRunner.java
 [v2]
In-Reply-To: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>
References: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>
Message-ID: <PuDo5_X8yjiu3xauay43ELt5505ajty1BtR0TQagG8o=.efe3a16d-ff06-4202-859b-9629263ba441@github.com>

> Small patch of cleaning up no longer used data structures after testing is complete. 
> 
> Test: tier1-5

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 stress-free-memory
 - stress-free-memory

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27606/files
  - new: https://git.openjdk.org/jdk/pull/27606/files/58f36e18..5043238e

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

  Stats: 7191 lines in 335 files changed: 3991 ins; 1601 del; 1599 mod
  Patch: https://git.openjdk.org/jdk/pull/27606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27606/head:pull/27606

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

From shade at openjdk.org  Mon Oct  6 10:05:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 10:05:48 GMT
Subject: RFR: 8369041: Release memory after testing in ThreadsRunner.java
 [v2]
In-Reply-To: <PuDo5_X8yjiu3xauay43ELt5505ajty1BtR0TQagG8o=.efe3a16d-ff06-4202-859b-9629263ba441@github.com>
References: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>
 <PuDo5_X8yjiu3xauay43ELt5505ajty1BtR0TQagG8o=.efe3a16d-ff06-4202-859b-9629263ba441@github.com>
Message-ID: <VrcQxyj5lKp45Cf9tynPmZRrago7XduLXnHm89T_AQg=.9689d867-1608-40cc-84b7-55bb8ec2f211@github.com>

On Mon, 6 Oct 2025 10:03:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Small patch of cleaning up no longer used data structures after testing is complete. 
>> 
>> Test: tier1-5
>
> 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 stress-free-memory
>  - stress-free-memory

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27606#pullrequestreview-3303691641

From duke at openjdk.org  Mon Oct  6 11:23:49 2025
From: duke at openjdk.org (duke)
Date: Mon, 6 Oct 2025 11:23:49 GMT
Subject: RFR: 8364927: Add @requires annotation to
 TestReclaimStringsLeaksMemory.java [v4]
In-Reply-To: <PLOezVqgn3s1lf9gNlvL1Zy1L0sHWkgVKe2YBZSPLDM=.068267f5-70d3-46e5-bb68-471cd6e570c6@github.com>
References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com>
 <PLOezVqgn3s1lf9gNlvL1Zy1L0sHWkgVKe2YBZSPLDM=.068267f5-70d3-46e5-bb68-471cd6e570c6@github.com>
Message-ID: <PUU_IL1ZWsesrJP0mXSTrf4v8Ef9ELeGxTu_YAXkNMM=.34313b7d-4025-4691-b1f4-e81db8457c3f@github.com>

On Mon, 8 Sep 2025 22:52:19 GMT, jonghoonpark <duke at openjdk.org> wrote:

>> This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments.
>> Previously, the test only checked `@requires vm.gc == "null"`.
>> 
>> The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported.
>> 
>> This prevents test failures on VMs that do not support the specified GC.
>> 
>> (This is my first contribution to the JDK. Thank you for your review and guidance.)
>
> jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8364927-add-requires-annotation
>  - remove non-specific GC test item and include ZGC and Shenandoah
>    
>    Signed-off-by: jonghoonpark <dev at jonghoonpark.com>
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8364927-add-requires-annotation
>  - 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java
>    
>    Signed-off-by: jonghoonpark <dev at jonghoonpark.com>

@dev-jonghoonpark 
Your change (at version 09b5f7c2ccc7bf4b2e68906709b73c48190d1ea3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26766#issuecomment-3371125435

From tschatzl at openjdk.org  Mon Oct  6 11:50:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 6 Oct 2025 11:50:47 GMT
Subject: RFR: 8369041: Release memory after testing in ThreadsRunner.java
 [v2]
In-Reply-To: <PuDo5_X8yjiu3xauay43ELt5505ajty1BtR0TQagG8o=.efe3a16d-ff06-4202-859b-9629263ba441@github.com>
References: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>
 <PuDo5_X8yjiu3xauay43ELt5505ajty1BtR0TQagG8o=.efe3a16d-ff06-4202-859b-9629263ba441@github.com>
Message-ID: <Q_sD0KT7_O4gAG1nA1x5NvtsvzZXV5i0XJudFPiG538=.4bc3a272-43c4-4574-834d-654c92a008d0@github.com>

On Mon, 6 Oct 2025 10:03:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Small patch of cleaning up no longer used data structures after testing is complete. 
>> 
>> Test: tier1-5
>
> 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 stress-free-memory
>  - stress-free-memory

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27606#pullrequestreview-3304128909

From tschatzl at openjdk.org  Mon Oct  6 11:52:48 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 6 Oct 2025 11:52:48 GMT
Subject: RFR: 8364927: Add @requires annotation to
 TestReclaimStringsLeaksMemory.java [v4]
In-Reply-To: <PLOezVqgn3s1lf9gNlvL1Zy1L0sHWkgVKe2YBZSPLDM=.068267f5-70d3-46e5-bb68-471cd6e570c6@github.com>
References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com>
 <PLOezVqgn3s1lf9gNlvL1Zy1L0sHWkgVKe2YBZSPLDM=.068267f5-70d3-46e5-bb68-471cd6e570c6@github.com>
Message-ID: <Nfhr8C1Xn_H6f0qsZTI9K0Ct7UsNQI5q2I0u1h4a-Pc=.f733c8c1-a07b-4ba0-a410-6f4680c91c38@github.com>

On Mon, 8 Sep 2025 22:52:19 GMT, jonghoonpark <duke at openjdk.org> wrote:

>> This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments.
>> Previously, the test only checked `@requires vm.gc == "null"`.
>> 
>> The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported.
>> 
>> This prevents test failures on VMs that do not support the specified GC.
>> 
>> (This is my first contribution to the JDK. Thank you for your review and guidance.)
>
> jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8364927-add-requires-annotation
>  - remove non-specific GC test item and include ZGC and Shenandoah
>    
>    Signed-off-by: jonghoonpark <dev at jonghoonpark.com>
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8364927-add-requires-annotation
>  - 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java
>    
>    Signed-off-by: jonghoonpark <dev at jonghoonpark.com>

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26766#pullrequestreview-3304136805

From duke at openjdk.org  Mon Oct  6 11:56:00 2025
From: duke at openjdk.org (jonghoonpark)
Date: Mon, 6 Oct 2025 11:56:00 GMT
Subject: Integrated: 8364927: Add @requires annotation to
 TestReclaimStringsLeaksMemory.java
In-Reply-To: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com>
References: <4aT8v-HYcfSoxEEDZZWhw2JjNXxvE1WUDDsYgV7n0I8=.1aef56d4-5a50-4be3-90bf-d57e5a54118b@github.com>
Message-ID: <cm1273nOzTMTBh--5O2fMpuCFdD4PeGAevcxkvCG9EE=.6414d7fb-2a44-4aea-9b09-da34bd62117c@github.com>

On Wed, 13 Aug 2025 19:11:25 GMT, jonghoonpark <duke at openjdk.org> wrote:

> This change updates `TestReclaimStringsLeaksMemory.java` to properly guard against unsupported GC arguments.
> Previously, the test only checked `@requires vm.gc == "null"`.
> 
> The fix separates the tests and adds explicit `@requires` clauses for each GC configuration to ensure the test only runs when supported.
> 
> This prevents test failures on VMs that do not support the specified GC.
> 
> (This is my first contribution to the JDK. Thank you for your review and guidance.)

This pull request has now been integrated.

Changeset: 2bfada3f
Author:    jonghoonpark <dev at jonghoonpark.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bfada3f58df6c041d948267368cbc4db915cac3
Stats:     46 lines in 1 file changed: 42 ins; 1 del; 3 mod

8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java

Reviewed-by: tschatzl, stefank, ayang

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

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

From fandreuzzi at openjdk.org  Mon Oct  6 14:33:42 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 6 Oct 2025 14:33:42 GMT
Subject: RFR: 8369178: G1: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in G1RootProcessor
In-Reply-To: <Mrp6vRYKL2cC0KQx2AMV22Kx8TJqJNM2A7S94EEInII=.90930ea6-cca4-4803-be0c-61723cf7feb2@github.com>
References: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
 <Mrp6vRYKL2cC0KQx2AMV22Kx8TJqJNM2A7S94EEInII=.90930ea6-cca4-4803-be0c-61723cf7feb2@github.com>
Message-ID: <xkAUxRIpHAJb6VuBPzuFv9zw_2jMb6GWsH6KvG8_3fw=.6b62758b-1119-46dc-9c80-681c65b667fd@github.com>

On Mon, 6 Oct 2025 14:10:31 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` and `MarkingNMethodClosure` in `G1RootProcessor ` to be more precise with what is needed and why.
>> 
>> - `MarkingNMethodClosure` is used in `G1FullGCMarkTask`, so we also need `NMethodMarkingScope`.
>> - `active_workers ` is guaranteed to be `> 0`
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> src/hotspot/share/gc/g1/g1RootProcessor.hpp line 54:
> 
>> 52:   NMethodMarkingScope _nmethod_marking_scope;
>> 53:   ThreadsClaimTokenScope _threads_claim_token_scope;
>> 54:   bool _is_parallel;
> 
> I would have used `uint _num_workers`, but I guess this also works.

We don't need to know how many workers there are, just if we are parallel or not. I think this goes in the same direction as the idea of the PR, being clear about what we actually need

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27644#discussion_r2406680110

From wkemper at openjdk.org  Mon Oct  6 14:51:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 6 Oct 2025 14:51:55 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v2]
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: <Z88Hi5_5tHlIfwhS5jfhyTafascR-8Dl380TKmUPkbM=.14e02bc6-f909-4680-94d9-e4aed15d73d2@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:

  Fix windows build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27632/files
  - new: https://git.openjdk.org/jdk/pull/27632/files/fd9619dd..8fca0b68

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

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 wkemper at openjdk.org  Mon Oct  6 15:36:59 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 6 Oct 2025 15:36:59 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v3]
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: <50uKtYv5OrEm6XAdBu-5NkZVsbP8t2pV4VBtDvV8Lys=.71995eda-8d3a-433d-80ac-efae58bc0d88@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:

  Fix windows build more

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27632/files
  - new: https://git.openjdk.org/jdk/pull/27632/files/8fca0b68..09926eb2

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 ayang at openjdk.org  Mon Oct  6 15:44:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 Oct 2025 15:44:17 GMT
Subject: RFR: 8369041: Release memory after testing in ThreadsRunner.java
 [v2]
In-Reply-To: <PuDo5_X8yjiu3xauay43ELt5505ajty1BtR0TQagG8o=.efe3a16d-ff06-4202-859b-9629263ba441@github.com>
References: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>
 <PuDo5_X8yjiu3xauay43ELt5505ajty1BtR0TQagG8o=.efe3a16d-ff06-4202-859b-9629263ba441@github.com>
Message-ID: <TC2q_7Kczy66vz2eJvpaiXegEoVrJkNj_BuM_b2PVAg=.b04d312a-fb57-4ebb-9650-b4ab6d9c4bf2@github.com>

On Mon, 6 Oct 2025 10:03:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Small patch of cleaning up no longer used data structures after testing is complete. 
>> 
>> Test: tier1-5
>
> 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 stress-free-memory
>  - stress-free-memory

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27606#issuecomment-3372374931

From ayang at openjdk.org  Mon Oct  6 15:47:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 Oct 2025 15:47:43 GMT
Subject: Integrated: 8369041: Release memory after testing in
 ThreadsRunner.java
In-Reply-To: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>
References: <tvfbhKGQDI4asFbpWtc6MsLw7T3Kx8JhcicpQPJwhSQ=.ec89d1c8-8801-46cc-8377-9397ad3eb41b@github.com>
Message-ID: <e1m9znKAjkY-6EAHEk4HPdVRkWUz4Mvg68jL6UH5im0=.91b6fd9e-9261-49de-9f1f-8930f14eefc8@github.com>

On Thu, 2 Oct 2025 11:16:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Small patch of cleaning up no longer used data structures after testing is complete. 
> 
> Test: tier1-5

This pull request has now been integrated.

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

8369041: Release memory after testing in ThreadsRunner.java

Reviewed-by: shade, tschatzl

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

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

From wkemper at openjdk.org  Mon Oct  6 18:44:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 6 Oct 2025 18:44:25 GMT
Subject: RFR: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate [v2]
In-Reply-To: <GkWjWcWY8Ovl9DIitUg2ivSxP2a9cZchgGEq1WVmsuE=.aa4fa2e3-81e8-403a-a1e8-f71c2b609119@github.com>
References: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
 <GkWjWcWY8Ovl9DIitUg2ivSxP2a9cZchgGEq1WVmsuE=.aa4fa2e3-81e8-403a-a1e8-f71c2b609119@github.com>
Message-ID: <u_-9XyNOlTKBOb_86luF8JK_2PwB_42OT-10Jxi9alk=.71e4e823-1fc9-4734-b5fd-26cab92aee6e@github.com>

On Sat, 27 Sep 2025 23:13:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Add documentation to ShenandoahAllocationRate
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix several typos

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27505#pullrequestreview-3306576679

From wkemper at openjdk.org  Mon Oct  6 22:07:24 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 6 Oct 2025 22:07:24 GMT
Subject: RFR: 8367646: [GenShen] Control thread may overwrite gc cancellation
 cause set by mutator
Message-ID: <RkO54i4ljRW9vD9TgxLmiXr5d513yDJXfjaoT8A4V7A=.d9716380-6be9-4b04-a588-621fc81621db@github.com>

I believe the following events could lead to this assertion failure:
1. Control thread reads the heap's gc cancellation cause as `shenandoah_concurrent_gc` 
2. Mutator thread has an allocation failure and sets the heap's gc cancellation cause to `shenandoah_alloc_failure`
3. Control thread uses stale value from `1` and decides to unconditionally clear the cancellation cause
4. Mutator thread assert that gc is still cancelled

The proposed fix here has the control thread use a CAS operation to only clear the gc if the existing value if `shenandoah_concurrent_gc`. This will stop the control thread from erroneously changing the value if a mutator has already set it to `shenandoah_alloc_failure`. A mutator thread may still have an allocation failure after the control thread has cleared the cancellation, but this is normal and expected.

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

Commit messages:
 - Fix race between mutator and control thread over gc cancellation

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

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

From kdnilsen at openjdk.org  Mon Oct  6 22:20:45 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 6 Oct 2025 22:20:45 GMT
Subject: RFR: 8367646: [GenShen] Control thread may overwrite gc
 cancellation cause set by mutator
In-Reply-To: <RkO54i4ljRW9vD9TgxLmiXr5d513yDJXfjaoT8A4V7A=.d9716380-6be9-4b04-a588-621fc81621db@github.com>
References: <RkO54i4ljRW9vD9TgxLmiXr5d513yDJXfjaoT8A4V7A=.d9716380-6be9-4b04-a588-621fc81621db@github.com>
Message-ID: <CSypyMsN98g18854HjNSF9DGdMFzr6MKq4cOzkyiu5A=.b230a46d-881b-490f-8f6a-ac9e613be3db@github.com>

On Mon, 6 Oct 2025 22:00:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I believe the following events could lead to this assertion failure:
> 1. Control thread reads the heap's gc cancellation cause as `shenandoah_concurrent_gc` 
> 2. Mutator thread has an allocation failure and sets the heap's gc cancellation cause to `shenandoah_alloc_failure`
> 3. Control thread uses stale value from `1` and decides to unconditionally clear the cancellation cause
> 4. Mutator thread assert that gc is still cancelled
> 
> The proposed fix here has the control thread use a CAS operation to only clear the gc if the existing value if `shenandoah_concurrent_gc`. This will stop the control thread from erroneously changing the value if a mutator has already set it to `shenandoah_alloc_failure`. A mutator thread may still have an allocation failure after the control thread has cleared the cancellation, but this is normal and expected.

There's a typo in description of the issue: s/if/is/

Have we been able to confirm through testing that this resolves the previously observed assertion failure?

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27662#pullrequestreview-3307686078

From wkemper at openjdk.org  Mon Oct  6 22:31:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 6 Oct 2025 22:31:50 GMT
Subject: RFR: 8367646: [GenShen] Control thread may overwrite gc
 cancellation cause set by mutator
In-Reply-To: <RkO54i4ljRW9vD9TgxLmiXr5d513yDJXfjaoT8A4V7A=.d9716380-6be9-4b04-a588-621fc81621db@github.com>
References: <RkO54i4ljRW9vD9TgxLmiXr5d513yDJXfjaoT8A4V7A=.d9716380-6be9-4b04-a588-621fc81621db@github.com>
Message-ID: <GYWGEV1D2ge_f7sbJbdGBpDMQMIo2zAUyaMRqaoJE10=.72b72406-e672-4dd8-84bd-3738427f3f89@github.com>

On Mon, 6 Oct 2025 22:00:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I believe the following events could lead to this assertion failure:
> 1. Control thread reads the heap's gc cancellation cause as `shenandoah_concurrent_gc` 
> 2. Mutator thread has an allocation failure and sets the heap's gc cancellation cause to `shenandoah_alloc_failure`
> 3. Control thread uses stale value from `1` and decides to unconditionally clear the cancellation cause
> 4. Mutator thread assert that gc is still cancelled
> 
> The proposed fix here has the control thread use a CAS operation to only clear the gc if the existing value is `shenandoah_concurrent_gc`. This will stop the control thread from erroneously changing the value if a mutator has already set it to `shenandoah_alloc_failure`. A mutator thread may still have an allocation failure after the control thread has cleared the cancellation, but this is normal and expected.

I was never able to reproduce it. The crash was observed on somewhat exotic hardware. I'm fairly confident in the fix because in all other cases the cancellation cause is only cleared on a safepoint. That is to say, this code is the only place the collector clears the cancellation cause concurrently with mutators.

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

PR Comment: https://git.openjdk.org/jdk/pull/27662#issuecomment-3374480022

From kdnilsen at openjdk.org  Mon Oct  6 23:19:50 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 6 Oct 2025 23:19:50 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v3]
In-Reply-To: <50uKtYv5OrEm6XAdBu-5NkZVsbP8t2pV4VBtDvV8Lys=.71995eda-8d3a-433d-80ac-efae58bc0d88@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
 <50uKtYv5OrEm6XAdBu-5NkZVsbP8t2pV4VBtDvV8Lys=.71995eda-8d3a-433d-80ac-efae58bc0d88@github.com>
Message-ID: <B07ZMR5oqva_-U-J_QLEILuMdgqnfpBZp_z7LXF4W5E=.9e6ad068-70e5-4b72-9f65-abaa2ca439df@github.com>

On Mon, 6 Oct 2025 15:36:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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:
> 
>   Fix windows build more

I'm thinking that there should be a change to heap->rebuild_freeset() that adds get_promotion_potential() to the reserve for OldCollector.  We did not previously make this reserve because we were only counting data that was to be promoted in place.

This may have the effect of triggering a bit sooner than in existing master.  We could subtract out the pip_promo_reserve() if we want to keep track of that separately, because that doesn't need to be reserved.

Once the cset is constructed, we will shrink the reserves because at that point, we'll know better how much we really plan to evacuate into old.

src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp line 62:

> 60: 
> 61: size_t ShenandoahCollectionSet::get_live_bytes_in_young_regions() const {
> 62:   return _young_bytes_to_evacuate - _young_bytes_to_promote;

I'm wondering if these new names properly reflect the intention.  It seems get_live_byte_in_young_regions() really means get_live_bytes_that_we_intend_to_evacuate_to_young().  (This number does not include _live_bytes_in_young_regions() that we expect to evacuate to old.)

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

> 292:   // We have to be careful in the event that SOEP is set to 100 by the user.
> 293:   assert(ShenandoahOldEvacRatioPercent <= 100, "Error");
> 294:   const size_t ratio_of_old_in_collection_set = (maximum_young_evacuation_reserve * ShenandoahOldEvacRatioPercent) / (100 - ShenandoahOldEvacRatioPercent);

It looks like we may get divide-by-zero in the above of ShenandoahOldEvacRatioPercent equals 100

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

> 479:   // promotions than fit in reserved memory, they will be deferred until a future GC pass.
> 480:   size_t total_promotion_reserve = young_advance_promoted_reserve_used + excess_old;
> 481:   old_generation->set_promoted_reserve(total_promotion_reserve);

Can you clarify why we no longer need this set_promoted_reserve() call?  (just in a PR comment probably, not necessarily a code comment.)

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 305:

> 303:       }
> 304:       // else, we leave copy equal to nullptr, signaling a promotion failure below if appropriate.
> 305:       // We choose not to promote objects smaller than PLAB::min_size() by way of shared allocations, as this is too

I think this comment describes original behavior.  With new behavior, comment should say PLAB::max_size()

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

PR Review: https://git.openjdk.org/jdk/pull/27632#pullrequestreview-3307715360
PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2408855784
PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2408865186
PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2408949510
PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2408922323

From kdnilsen at openjdk.org  Mon Oct  6 23:19:51 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 6 Oct 2025 23:19:51 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v3]
In-Reply-To: <B07ZMR5oqva_-U-J_QLEILuMdgqnfpBZp_z7LXF4W5E=.9e6ad068-70e5-4b72-9f65-abaa2ca439df@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
 <50uKtYv5OrEm6XAdBu-5NkZVsbP8t2pV4VBtDvV8Lys=.71995eda-8d3a-433d-80ac-efae58bc0d88@github.com>
 <B07ZMR5oqva_-U-J_QLEILuMdgqnfpBZp_z7LXF4W5E=.9e6ad068-70e5-4b72-9f65-abaa2ca439df@github.com>
Message-ID: <P9SJbxBwJuz9RaqoH8602sSJPaLyei1unMTVED7OCM0=.209c02e6-5356-418e-844f-9056e44073fc@github.com>

On Mon, 6 Oct 2025 22:39:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build more
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 294:
> 
>> 292:   // We have to be careful in the event that SOEP is set to 100 by the user.
>> 293:   assert(ShenandoahOldEvacRatioPercent <= 100, "Error");
>> 294:   const size_t ratio_of_old_in_collection_set = (maximum_young_evacuation_reserve * ShenandoahOldEvacRatioPercent) / (100 - ShenandoahOldEvacRatioPercent);
> 
> It looks like we may get divide-by-zero in the above of ShenandoahOldEvacRatioPercent equals 100

In the original code, we only compute ratio_of_old_in_collection_set if ShenandoahOldEvacRatioPercent != 100

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2408872507

From ayang at openjdk.org  Tue Oct  7 08:23:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 08:23:41 GMT
Subject: RFR: 8369263: Parallel: Inline PSPromotionManager::push_depth
Message-ID: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>

Trivial inlining a method to its single caller.

Test: tier1

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

Commit messages:
 - pgc-trivial

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

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

From iwalulya at openjdk.org  Tue Oct  7 08:55:47 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 7 Oct 2025 08:55:47 GMT
Subject: RFR: 8369263: Parallel: Inline PSPromotionManager::push_depth
In-Reply-To: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
References: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
Message-ID: <AESwY_tjsUnXmTwSEyHAYHwUHh4pN3RmhkWv5hUIKE4=.cc7b5190-d149-4144-9bc7-4c241dac93dc@github.com>

On Tue, 7 Oct 2025 08:16:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its single caller.
> 
> Test: tier1

Trivial!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27668#pullrequestreview-3309096568

From jsikstro at openjdk.org  Tue Oct  7 09:15:34 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 7 Oct 2025 09:15:34 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v4]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <kIoRqz3UdU2Ft-DH1o3c6CeD7iwHaA1ZbTt1v-EZnL4=.16b72197-1058-4761-80fe-76fc45d7b53e@github.com>

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

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

  Revert MaxRAM default removals, defer to future enhancement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27224/files
  - new: https://git.openjdk.org/jdk/pull/27224/files/bd1f632e..2304c6aa

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

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

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

From shade at openjdk.org  Tue Oct  7 09:15:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Oct 2025 09:15:58 GMT
Subject: RFR: 8369263: Parallel: Inline PSPromotionManager::push_depth
In-Reply-To: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
References: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
Message-ID: <71AYjeybQ0jEDzLj1SK_0-IYJsfPW4pccZdQ-la-aLw=.1ae15cc0-9f41-4b98-9400-dc94430bb7b6@github.com>

On Tue, 7 Oct 2025 08:16:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its single caller.
> 
> Test: tier1

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27668#pullrequestreview-3309175579

From ayang at openjdk.org  Tue Oct  7 09:23:26 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 09:23:26 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v4]
In-Reply-To: <kIoRqz3UdU2Ft-DH1o3c6CeD7iwHaA1ZbTt1v-EZnL4=.16b72197-1058-4761-80fe-76fc45d7b53e@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <kIoRqz3UdU2Ft-DH1o3c6CeD7iwHaA1ZbTt1v-EZnL4=.16b72197-1058-4761-80fe-76fc45d7b53e@github.com>
Message-ID: <0JlKR_0U6obGNVYe0Os0c2Q1w6WR9F_o6gHjApjzLJM=.db81f2ce-a74c-40a8-9ae9-591b9684e787@github.com>

On Tue, 7 Oct 2025 09:15:34 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert MaxRAM default removals, defer to future enhancement

src/hotspot/share/runtime/arguments.cpp line 1514:

> 1512: 
> 1513:   // Check if the user has configured any limit on the amount of RAM we may use.
> 1514:   bool ram_limit_set = !FLAG_IS_DEFAULT(MaxRAMPercentage) ||

How about `has_ram_limit`/`is_ram_limit_set`?

src/hotspot/share/runtime/arguments.cpp line 1544:

> 1542:     uint64_t max_memory = (uint64_t)(((double)physical_memory * MaxRAMPercentage) / 100);
> 1543: 
> 1544:     const size_t reasonable_min = limit_by_size_t_max(min_memory);

I wonder whether we should emit a log-info/warning, if `limit_by_size_t_max` does change the result.

src/hotspot/share/runtime/arguments.cpp line 1590:

> 1588: 
> 1589:     if (UseCompressedOops) {
> 1590:       size_t heap_end = HeapBaseMinAddress + MaxHeapSize;

I wonder if this is a pre-existing issue: `HeapBaseMinAddress` , according to its name, sounds like a `uintptr_t` instead of `size_t`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2409967306
PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2409970585
PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2409973796

From jsikstro at openjdk.org  Tue Oct  7 09:34:19 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 7 Oct 2025 09:34:19 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

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

  Rename ram_limit_set to has_ram_limit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27224/files
  - new: https://git.openjdk.org/jdk/pull/27224/files/2304c6aa..c6e585e2

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

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

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

From jsikstro at openjdk.org  Tue Oct  7 09:34:21 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 7 Oct 2025 09:34:21 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v4]
In-Reply-To: <0JlKR_0U6obGNVYe0Os0c2Q1w6WR9F_o6gHjApjzLJM=.db81f2ce-a74c-40a8-9ae9-591b9684e787@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <kIoRqz3UdU2Ft-DH1o3c6CeD7iwHaA1ZbTt1v-EZnL4=.16b72197-1058-4761-80fe-76fc45d7b53e@github.com>
 <0JlKR_0U6obGNVYe0Os0c2Q1w6WR9F_o6gHjApjzLJM=.db81f2ce-a74c-40a8-9ae9-591b9684e787@github.com>
Message-ID: <cbExN6kX2oAk4Fo6KY8ZhWY7iZHiCMH-__EXQLh6yh4=.1fb6351c-0b03-4e32-a684-16bd715a79f7@github.com>

On Tue, 7 Oct 2025 09:19:03 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:
>> 
>>   Revert MaxRAM default removals, defer to future enhancement
>
> src/hotspot/share/runtime/arguments.cpp line 1544:
> 
>> 1542:     uint64_t max_memory = (uint64_t)(((double)physical_memory * MaxRAMPercentage) / 100);
>> 1543: 
>> 1544:     const size_t reasonable_min = limit_by_size_t_max(min_memory);
> 
> I wonder whether we should emit a log-info/warning, if `limit_by_size_t_max` does change the result.

I'm a bit hesitant to add non-debug logging here as I don't have resources to test this on a 32-bit VM. Also, I'm not sure how much extra code we'd like to have for 32-bit support.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2410006373

From ayang at openjdk.org  Tue Oct  7 10:29:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 10:29:58 GMT
Subject: RFR: 8369277: Remove unused CodeCacheUnloadingTask::_num_workers
Message-ID: <TBV9BIj-NS-K0hvup9sbAX3zesTJZ-OJ_6sCNdkUvx8=.035ca498-170e-42bc-91b7-76c52747a19e@github.com>

Trivial removing dead code.

Test: tier1

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

Commit messages:
 - remove-field-trivial

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

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

From ayang at openjdk.org  Tue Oct  7 11:08:20 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 11:08:20 GMT
Subject: RFR: 8369277: Remove unused CodeCacheUnloadingTask::_num_workers
 [v2]
In-Reply-To: <TBV9BIj-NS-K0hvup9sbAX3zesTJZ-OJ_6sCNdkUvx8=.035ca498-170e-42bc-91b7-76c52747a19e@github.com>
References: <TBV9BIj-NS-K0hvup9sbAX3zesTJZ-OJ_6sCNdkUvx8=.035ca498-170e-42bc-91b7-76c52747a19e@github.com>
Message-ID: <5LV-BeT8q4lKJmbjUlAhqPtRFHGXZzrCVHkJkbh0RZU=.2e3a549e-7427-4b63-8d52-60ee33549fef@github.com>

> Trivial removing dead code.
> 
> Test: tier1

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

  more-remove

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27671/files
  - new: https://git.openjdk.org/jdk/pull/27671/files/41e4307b..dc5ab249

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

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

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

From shade at openjdk.org  Tue Oct  7 12:29:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Oct 2025 12:29:43 GMT
Subject: RFR: 8369277: Remove unused CodeCacheUnloadingTask::_num_workers
 [v2]
In-Reply-To: <5LV-BeT8q4lKJmbjUlAhqPtRFHGXZzrCVHkJkbh0RZU=.2e3a549e-7427-4b63-8d52-60ee33549fef@github.com>
References: <TBV9BIj-NS-K0hvup9sbAX3zesTJZ-OJ_6sCNdkUvx8=.035ca498-170e-42bc-91b7-76c52747a19e@github.com>
 <5LV-BeT8q4lKJmbjUlAhqPtRFHGXZzrCVHkJkbh0RZU=.2e3a549e-7427-4b63-8d52-60ee33549fef@github.com>
Message-ID: <2iqk66b2BhR4MXe9s3khC8keJFT5m8_nsCXeUDJmwcw=.68318cd9-1776-4645-8da6-ad2a271afec5@github.com>

On Tue, 7 Oct 2025 11:08:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing dead code.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more-remove

src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.cpp line 39:

> 37:   _phase(phase),
> 38:   _unloading_occurred(unloading_occurred),
> 39:   _code_cache_task(unloading_occurred),

`ShenandoahClassUnloadingTask` constructor argument `num_workers` is also unused now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27671#discussion_r2410456344

From ayang at openjdk.org  Tue Oct  7 12:35:20 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 12:35:20 GMT
Subject: RFR: 8369277: Remove unused CodeCacheUnloadingTask::_num_workers
 [v3]
In-Reply-To: <TBV9BIj-NS-K0hvup9sbAX3zesTJZ-OJ_6sCNdkUvx8=.035ca498-170e-42bc-91b7-76c52747a19e@github.com>
References: <TBV9BIj-NS-K0hvup9sbAX3zesTJZ-OJ_6sCNdkUvx8=.035ca498-170e-42bc-91b7-76c52747a19e@github.com>
Message-ID: <FnBn79602us5ftzGHNtcqxEpeIgX8O3Y5-P1DKmbPW0=.51695059-a7d5-4a4a-8b4f-26184c1f1f69@github.com>

> Trivial removing dead code.
> 
> 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/27671/files
  - new: https://git.openjdk.org/jdk/pull/27671/files/dc5ab249..be17b8bf

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

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

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

From ayang at openjdk.org  Tue Oct  7 12:43:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 12:43:39 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5]
In-Reply-To: <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
Message-ID: <bDKs5xn1pabzX2qKNk3JNMM6mscmLlcABWrzywGkiBM=.dd00b428-d643-4096-821e-ba6f814a2eb3@github.com>

On Tue, 7 Oct 2025 09:34:19 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ram_limit_set to has_ram_limit

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3309934893

From ayang at openjdk.org  Tue Oct  7 13:17:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 13:17:12 GMT
Subject: RFR: 8369277: Remove unused CodeCacheUnloadingTask::_num_workers
 [v4]
In-Reply-To: <TBV9BIj-NS-K0hvup9sbAX3zesTJZ-OJ_6sCNdkUvx8=.035ca498-170e-42bc-91b7-76c52747a19e@github.com>
References: <TBV9BIj-NS-K0hvup9sbAX3zesTJZ-OJ_6sCNdkUvx8=.035ca498-170e-42bc-91b7-76c52747a19e@github.com>
Message-ID: <sxPCKFyb1Bg_QMynnXD_Xk0SJ5VSubnwW2pjWrOXSIQ=.28e1d400-e3d3-4e0c-8830-557011307fcd@github.com>

> Trivial removing dead code.
> 
> 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/27671/files
  - new: https://git.openjdk.org/jdk/pull/27671/files/be17b8bf..aea09613

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

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

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

From ayang at openjdk.org  Tue Oct  7 13:18:18 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 13:18:18 GMT
Subject: RFR: 8369286: Parallel: Assertion failure in mutableNUMASpace
Message-ID: <FahdRTMW87-vcf7ORDd8PklkX1_3a_AACrC7knCoEoQ=.3a9421e9-6701-4e12-ac53-f90342d6a52f@github.com>

Parallel will try to expand eden to satisfy allocation request. However, the current NUMA implementation in Parallel requires a space to be empty on resizing so that the memory inside the space can be freely distributed among all NUMA nodes.

Add an early-return to `PSYoungGen::try_expand_to_hold` if NUMA is enabled and eden is not empty.

Test: tier1-3

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

Commit messages:
 - pgc-eden-numa

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

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

From duke at openjdk.org  Tue Oct  7 13:24:40 2025
From: duke at openjdk.org (duke)
Date: Tue, 7 Oct 2025 13:24:40 GMT
Subject: RFR: 8369178: G1: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in G1RootProcessor
In-Reply-To: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
References: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
Message-ID: <Jr5jbrFyE9vSXjE0R6_qTe-80DQNfXuJsQLVBrmQ49I=.e035af2f-7daa-4cba-9279-960ee614ae02@github.com>

On Mon, 6 Oct 2025 12:20:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` and `MarkingNMethodClosure` in `G1RootProcessor ` to be more precise with what is needed and why.
> 
> - `MarkingNMethodClosure` is used in `G1FullGCMarkTask`, so we also need `NMethodMarkingScope`.
> - `active_workers ` is guaranteed to be `> 0`
> 
> Passes tier1 and tier2 (fastdebug).

@fandreuz 
Your change (at version 131f636cf09ab166d786210868a2197fa4d62565) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27644#issuecomment-3376875929

From fandreuzzi at openjdk.org  Tue Oct  7 13:25:43 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 7 Oct 2025 13:25:43 GMT
Subject: RFR: 8369263: Parallel: Inline PSPromotionManager::push_depth
In-Reply-To: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
References: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
Message-ID: <XsM9sfErLQG-5ntmQq-YRBmvH6g0OqxeRVvVakBLi8s=.af6b5b17-97af-491c-a5c5-93bebbd7cee5@github.com>

On Tue, 7 Oct 2025 08:16:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its single caller.
> 
> Test: tier1

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27668#pullrequestreview-3310104562

From ayang at openjdk.org  Tue Oct  7 13:42:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 13:42:39 GMT
Subject: RFR: 8369263: Parallel: Inline PSPromotionManager::push_depth
In-Reply-To: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
References: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
Message-ID: <DN88nQuF9-IzLSKXFKc0lqyUMzzaUQQRtKYAvuS28hY=.83e35932-2bd7-4aeb-a169-49dbf04709ee@github.com>

On Tue, 7 Oct 2025 08:16:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its single caller.
> 
> Test: tier1

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27668#issuecomment-3376945904

From ayang at openjdk.org  Tue Oct  7 13:42:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 13:42:40 GMT
Subject: Integrated: 8369263: Parallel: Inline PSPromotionManager::push_depth
In-Reply-To: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
References: <cz7Wi2yKNbkFdwc48MLXC8N19rjF6ccI_AIu_iwWi4I=.c65e1b55-f669-496f-86f7-22ec490ba292@github.com>
Message-ID: <WygS6WM7a8TMGwiXxPv_NdgCqfQa4D-ePgTY_FUji9Y=.ddce5418-7dba-42db-8175-dc264b4018ef@github.com>

On Tue, 7 Oct 2025 08:16:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to its single caller.
> 
> Test: tier1

This pull request has now been integrated.

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

8369263: Parallel: Inline PSPromotionManager::push_depth

Reviewed-by: iwalulya, shade, fandreuzzi

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

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

From jsikstro at openjdk.org  Tue Oct  7 13:55:26 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 7 Oct 2025 13:55:26 GMT
Subject: RFR: 8369286: Parallel: Assertion failure in mutableNUMASpace
In-Reply-To: <FahdRTMW87-vcf7ORDd8PklkX1_3a_AACrC7knCoEoQ=.3a9421e9-6701-4e12-ac53-f90342d6a52f@github.com>
References: <FahdRTMW87-vcf7ORDd8PklkX1_3a_AACrC7knCoEoQ=.3a9421e9-6701-4e12-ac53-f90342d6a52f@github.com>
Message-ID: <CYpS66GZ5OdsBpfTzm2QUYjEBQSr7Ya2PKDigecurGM=.9f54b9db-0cb7-4d1d-b24e-7508b0f10b1b@github.com>

On Tue, 7 Oct 2025 13:10:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Parallel will try to expand eden to satisfy allocation request. However, the current NUMA implementation in Parallel requires a space to be empty on resizing so that the memory inside the space can be freely distributed among all NUMA nodes.
> 
> Add an early-return to `PSYoungGen::try_expand_to_hold` if NUMA is enabled and eden is not empty.
> 
> Test: tier1-3

Looks good.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27675#pullrequestreview-3310235099

From kdnilsen at openjdk.org  Tue Oct  7 15:24:24 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 15:24:24 GMT
Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild
Message-ID: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@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.

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

Commit messages:
 - Revert "revert introduction of RebuildLock"
 - Revert "available() returns previous value if called during freeset rebuild"
 - Revert "remove obsolete assertion"
 - remove obsolete assertion
 - available() returns previous value if called during freeset rebuild
 - revert introduction of RebuildLock
 - reduce gratuitous diffs from tip
 - Treat traditional Shenandoah same as Generational Shenandoah
 - fix whitespace
 - Add support for freeset rebuild lock

Changes: https://git.openjdk.org/jdk/pull/27612/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27612&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369048
  Stats: 37 lines in 5 files changed: 20 ins; 0 del; 17 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 kdnilsen at openjdk.org  Tue Oct  7 15:24:24 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 15:24:24 GMT
Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during
 rebuild
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: <CG7F0rQq8e3pbWfhM7m15KQa46sN2iJ3yOaPziTsNTw=.fc2b2597-9807-45fa-8994-3f32c8aea14f@github.com>

On Thu, 2 Oct 2025 17:58:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

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

Will identify this PR as draft until I complete performance and correctness tests.

I have these results from running Extremem tests on commit 99d0175

<img width="2010" height="896" alt="image" src="https://github.com/user-attachments/assets/20596fd4-fb4f-485c-97a4-643adfe25935" />

I am going to try an experiment with a different approach.  I will remove the synchronization lock and instead will cause the implementation of freeset rebuild to not update available() until after it is done with its work.  I think this may address the same problem with less run-time overhead.

On the same workload, here are the results of the experiment (rather than locking to prevent fetch of available during rebuild, we continue to return the value of available at the start of rebuild until rebuild finishes):

<img width="2009" height="454" alt="image" src="https://github.com/user-attachments/assets/33b38c57-8739-4814-8351-665c0aab0de2" />

General observations are that:

1. CPU utilization increased for both GenShen and Shen.
2. Number of completed GCs increased for GenShen but decreased for Shen
3. Shen degenerated GCs increased
4. GenShen P50 latency increased, but p95, p99, and p99.9 latencies decreased.  Higher latencies all increased for GenShen.
5. Shen latencies are worse at all percentiles.

Qualitatively, what would we expect?  If we return an old value for available() during freeset rebuild, we are usually causing triggering heuristics to believe there is less memory available than is actually available.  This may cause us to trigger GC more aggressively.  This bears out for GenShen, but not for Shen.

With GenShen, the critical conflict occurs when old marking has completed, and we rebuild the free set following old marking in order to recycle immediate old garbage and to set aside old-collector reserves which will be required for anticipated mixed evacuation GC cycles that will immediately follow.  While this is happening, the Shenandoah regulator thread is trying to decide whether it should interrupt old GC in order to perform an "urgent" young GC cycle.  And sometimes, the regulator thread's inquiry as to how much memory is available sees a bogus (not just stale, but out of thin air) value because the freeset is under construction at the time of its inquiry.  Preventing this bogus value is the point of this PR.

This situation does not generally happen with traditional Shenandoah.  Traditional Shenandoah only queries the available() during times when GC is idle.  (There are plans to change this, to allow the freeset to be rebuilt more asynchronously, so we are testing this coordination mechanism out for both GenShen and Shen.). A plausible explanation for the observed impact on Shen is that the absence of synchronization allows Shen to see more stale values of available(), even when we are not conflicting with concurrent freeset rebuilds.  Specifically, if we gnawing away on available memory, probing available() every ms, the triggering heuristic may see the same value of available() for three consecutive probes.  Not recognizing that memory has been consumed, it will delay triggering of the next GC cycle, resulting in fewer concurrent GCs with the "unsynchronized" solution.  Besides resulting in fewer GC cycles, the late triggers also allow us to get closer to total depletion of the allocat
 able memory pool, which explains an increase in Shenandoah degenerated cycles.

Presumably, GenShen is also vulnerable to this possibility.  But the benefit of eliminating out-of-thin-air available values for GenShen seems to outweigh the risk of occasional stale values that cause late triggers.

For further context, here are CI pipeline performance summaries for the initial synchronized solution:

   Control: openjdk-master-aarch64
Experiment: synchronize-available-with-rebuild-gh-aarch64

Genshen
-------------------------------------------------------------------------------------------------------
+45.80% specjbb2015/trigger_failure p=0.00542
  Control:    365.562   (+/-158.45  )        109
  Test:       533.000   (+/-200.37  )         10

+28.53% scimark.lu.large/concurrent_update_refs_young p=0.00020
  Control:      5.608ms (+/-  1.91ms)         34
  Test:         7.208ms (+/-107.48us)          2

+24.44% specjbb2015/concurrent_update_refs_degen_young p=0.00563
  Control:    804.287ms (+/-330.68ms)         41
  Test:         1.001s  (+/-101.83ms)          8

and for the "unsynchronized" solution:

   Control: openjdk-master-aarch64
Experiment: synchronize-available-with-rebuild-gh-aarch64

Genshen
-------------------------------------------------------------------------------------------------------
+51.82% hyperalloc_a2048_o4096/finish_mark_degen_young p=0.00771
  Control:     82.769ms (+/- 66.46ms)         66
  Test:       125.658ms (+/- 78.91ms)         43

The p values for all of these measures are a bit high, based on limited samples of relevant data.  The unsynchronized data result is combined with previous measurements taken from the synchronized experiments.

One other somewhat subjective observation is that the synchronized solution experienced many more "timeout" failures on the CI pipeline than the unsynchronized solution.  These timeout failures correlate with stress workloads that exercise the JVM in abnormal/extreme ways.  Under these stresses, the unsynchronized mechanism seems to be a bit more robust.

I'm inclined to prefer the synchronized solution so will revert my most recent three commits.

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

PR Comment: https://git.openjdk.org/jdk/pull/27612#issuecomment-3362378108
PR Comment: https://git.openjdk.org/jdk/pull/27612#issuecomment-3372885805
PR Comment: https://git.openjdk.org/jdk/pull/27612#issuecomment-3377284428
PR Comment: https://git.openjdk.org/jdk/pull/27612#issuecomment-3377318918
PR Comment: https://git.openjdk.org/jdk/pull/27612#issuecomment-3377335205
PR Comment: https://git.openjdk.org/jdk/pull/27612#issuecomment-3377355113

From kdnilsen at openjdk.org  Tue Oct  7 16:27:56 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 16:27:56 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v15]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <V3zzvxYs_LLV-LVLzBo34scB1Rfy0Uod-WXHZLEWvmQ=.a8bd7b18-f7a3-473b-a5ee-638e7c3ab1bb@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  remove set_capacity() scaffolding from shenandoahOldGeneration.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/f6a1182e..5277bc1c

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

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

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

From kdnilsen at openjdk.org  Tue Oct  7 16:27:59 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 16:27:59 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v12]
In-Reply-To: <ln2G4t7R7LLurFDBeSHLzY4-bWw0D0oCVXsOeGegHUQ=.75155da3-905c-465e-bad1-a3c54fba9b0b@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <zykF_uZbCnQ24lXQ7WDVnnbofQqtZbm3THblcpqnUnc=.c22227ea-3a1b-4507-b4f1-b48368c80fa3@github.com>
 <ln2G4t7R7LLurFDBeSHLzY4-bWw0D0oCVXsOeGegHUQ=.75155da3-905c-465e-bad1-a3c54fba9b0b@github.com>
Message-ID: <NpYplxyoaCE7tKluGCwLscO2YBUpUhQD3wSg3kP8GdQ=.bbb9f7b0-ea1f-43ef-99a9-20013133741d@github.com>

On Thu, 2 Oct 2025 23:09:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - small refactoring
>>  - OO refinements to used_regions_size()
>>  - fix broken assert from previous commit
>>  - OO refinements to free_unaffiliated_regions()
>>  - OO refinements to max_capacity()
>
> src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp line 40:
> 
>> 38: 
>> 39: size_t ShenandoahGlobalGeneration::max_capacity() const {
>> 40: #ifdef ASSERT
> 
> Could we just have this assertion one time in the constructor?

Yes.  Making this change.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2411198002

From kdnilsen at openjdk.org  Tue Oct  7 16:28:01 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 16:28:01 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <SyTEnsVbORETKxSR_M2fDUBumz4BMIZSY0psPqg5g0o=.063c13b1-3cb6-43c6-9a09-27100db336db@github.com>
Message-ID: <FaUcc3ydziIKacXNMQfWLabqh8pXidt2EpX2lNRgmxE=.6291ba78-4c3f-4864-9287-17ce6a49952b@github.com>

On Fri, 12 Sep 2025 18:08:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another tweak to make GHA gtest happy
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 104:
> 
>> 102: 
>> 103:   // Use this only for unit testing.  Do not use for production.
>> 104:   inline void set_capacity(size_t bytes) {
> 
> We should be able to inline this code in `test_shenandoahOldHeuristic.cpp` in the constructor of the test fixture that calls this method.

Very good suggestion.  Thanks.  Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2411186964

From kdnilsen at openjdk.org  Tue Oct  7 16:42:14 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 16:42:14 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v12]
In-Reply-To: <ln2G4t7R7LLurFDBeSHLzY4-bWw0D0oCVXsOeGegHUQ=.75155da3-905c-465e-bad1-a3c54fba9b0b@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <zykF_uZbCnQ24lXQ7WDVnnbofQqtZbm3THblcpqnUnc=.c22227ea-3a1b-4507-b4f1-b48368c80fa3@github.com>
 <ln2G4t7R7LLurFDBeSHLzY4-bWw0D0oCVXsOeGegHUQ=.75155da3-905c-465e-bad1-a3c54fba9b0b@github.com>
Message-ID: <PDzoJ-QdEYa3qLY_05uIQtO7BSRWi7yIIPygo7-V2Xs=.b82e8701-f617-44b3-b680-0f3fcaa368c1@github.com>

On Thu, 2 Oct 2025 23:12:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - small refactoring
>>  - OO refinements to used_regions_size()
>>  - fix broken assert from previous commit
>>  - OO refinements to free_unaffiliated_regions()
>>  - OO refinements to max_capacity()
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 953:
> 
>> 951: }
>> 952: 
>> 953: size_t ShenandoahGeneration::max_capacity() const {
> 
> We never instantiate `ShenandoahGeneration` even non-generational mode gets `ShenandoahGlobalGeneration`. You could make these methods pure virtual. The implementation here should never be called.

Thanks.  Making this change also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2411236294

From wkemper at openjdk.org  Tue Oct  7 16:43:19 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 7 Oct 2025 16:43:19 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v3]
In-Reply-To: <P9SJbxBwJuz9RaqoH8602sSJPaLyei1unMTVED7OCM0=.209c02e6-5356-418e-844f-9056e44073fc@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
 <50uKtYv5OrEm6XAdBu-5NkZVsbP8t2pV4VBtDvV8Lys=.71995eda-8d3a-433d-80ac-efae58bc0d88@github.com>
 <B07ZMR5oqva_-U-J_QLEILuMdgqnfpBZp_z7LXF4W5E=.9e6ad068-70e5-4b72-9f65-abaa2ca439df@github.com>
 <P9SJbxBwJuz9RaqoH8602sSJPaLyei1unMTVED7OCM0=.209c02e6-5356-418e-844f-9056e44073fc@github.com>
Message-ID: <671VDUKCeU8fohCzUMiqfe5TIzbw9nu8EQopOKNjjrk=.aa24764e-7841-4eee-9af5-7c45317adc8a@github.com>

On Mon, 6 Oct 2025 22:41:42 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 294:
>> 
>>> 292:   // We have to be careful in the event that SOEP is set to 100 by the user.
>>> 293:   assert(ShenandoahOldEvacRatioPercent <= 100, "Error");
>>> 294:   const size_t ratio_of_old_in_collection_set = (maximum_young_evacuation_reserve * ShenandoahOldEvacRatioPercent) / (100 - ShenandoahOldEvacRatioPercent);
>> 
>> It looks like we may get divide-by-zero in the above of ShenandoahOldEvacRatioPercent equals 100
>
> In the original code, we only compute ratio_of_old_in_collection_set if ShenandoahOldEvacRatioPercent != 100

Good catch, I'll fix this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2411238898

From wkemper at openjdk.org  Tue Oct  7 16:43:24 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 7 Oct 2025 16:43:24 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v3]
In-Reply-To: <B07ZMR5oqva_-U-J_QLEILuMdgqnfpBZp_z7LXF4W5E=.9e6ad068-70e5-4b72-9f65-abaa2ca439df@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
 <50uKtYv5OrEm6XAdBu-5NkZVsbP8t2pV4VBtDvV8Lys=.71995eda-8d3a-433d-80ac-efae58bc0d88@github.com>
 <B07ZMR5oqva_-U-J_QLEILuMdgqnfpBZp_z7LXF4W5E=.9e6ad068-70e5-4b72-9f65-abaa2ca439df@github.com>
Message-ID: <HgFk4i0iXY8ZeweA2QkOSBliBk1ITtqWJOgX0PJCJ5c=.d95bba80-80ab-49bc-8510-004882cf8cc5@github.com>

On Mon, 6 Oct 2025 22:55:22 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build more
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 305:
> 
>> 303:       }
>> 304:       // else, we leave copy equal to nullptr, signaling a promotion failure below if appropriate.
>> 305:       // We choose not to promote objects smaller than PLAB::min_size() by way of shared allocations, as this is too
> 
> I think this comment describes original behavior.  With new behavior, comment should say PLAB::max_size()

Indeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2411239567

From kdnilsen at openjdk.org  Tue Oct  7 16:49:42 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 16:49:42 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v16]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <z6oOUZZTKGoXBk8IyhAmhXmPR9YLu7IvmoGf_O1Fcb8=.3b3afbeb-1fd3-4d82-b3b1-cedd11a5bd6e@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:

 - Make ShenandoahGeneration methods pure virtual
 - simplify assertions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/5277bc1c..510a4b8f

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

  Stats: 126 lines in 6 files changed: 10 ins; 107 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

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

From kdnilsen at openjdk.org  Tue Oct  7 17:02:46 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 17:02:46 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v17]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <QbPxwOD9F1MsUreyDy5LuRj88cJJwCKEcZfaYMvyXjs=.7c8a881d-4639-4d14-85a5-6d179f373ef3@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  revert gratuitous changes to shenandoahConcurrentGC.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/510a4b8f..bd8e7f76

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

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

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

From shade at openjdk.org  Tue Oct  7 17:11:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Oct 2025 17:11:23 GMT
Subject: RFR: 8369277: Remove unused CodeCacheUnloadingTask::_num_workers
 [v4]
In-Reply-To: <sxPCKFyb1Bg_QMynnXD_Xk0SJ5VSubnwW2pjWrOXSIQ=.28e1d400-e3d3-4e0c-8830-557011307fcd@github.com>
References: <TBV9BIj-NS-K0hvup9sbAX3zesTJZ-OJ_6sCNdkUvx8=.035ca498-170e-42bc-91b7-76c52747a19e@github.com>
 <sxPCKFyb1Bg_QMynnXD_Xk0SJ5VSubnwW2pjWrOXSIQ=.28e1d400-e3d3-4e0c-8830-557011307fcd@github.com>
Message-ID: <sDZWutjyGzEwMOrCic_59WLcWkR3bruzfheF5NmM_nM=.ac1a22f2-2a40-4d8f-b376-3522b6e808dc@github.com>

On Tue, 7 Oct 2025 13:17:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing dead code.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27671#pullrequestreview-3311065351

From kdnilsen at openjdk.org  Tue Oct  7 17:17:02 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 17:17:02 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v12]
In-Reply-To: <nSBP3szWwdm3T_aArPlKNtT1gnGZ0XOBBTiVYQGDxX4=.3b89009d-bc68-435d-b690-fab6711b3866@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <zykF_uZbCnQ24lXQ7WDVnnbofQqtZbm3THblcpqnUnc=.c22227ea-3a1b-4507-b4f1-b48368c80fa3@github.com>
 <nSBP3szWwdm3T_aArPlKNtT1gnGZ0XOBBTiVYQGDxX4=.3b89009d-bc68-435d-b690-fab6711b3866@github.com>
Message-ID: <317DjK8tXvEQesqN-YOVzUU652Ju6j3oBWRVPYTP_JM=.c0b7858f-28bd-4bf7-83af-33a7b10208db@github.com>

On Thu, 2 Oct 2025 23:20:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - small refactoring
>>  - OO refinements to used_regions_size()
>>  - fix broken assert from previous commit
>>  - OO refinements to free_unaffiliated_regions()
>>  - OO refinements to max_capacity()
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1153:
> 
>> 1151: void ShenandoahConcurrentGC::op_final_update_refs() {
>> 1152:   ShenandoahHeap* const heap = ShenandoahHeap::heap();
>> 1153:   bool is_generational = heap->mode()->is_generational();
> 
> Are the changes here necessary? This is a big PR, it would be helpful to minimize unnecessary changes.

I've reverted these changes.  Thanks.

> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1145:
> 
>> 1143:   _preserved_marks->reclaim();
>> 1144: 
>> 1145:   // We defer generation resizing actions until after cset regions have been recycled.  We do this even following an
> 
> Stale comment?

Yes.  Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2411316966
PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2411321130

From kdnilsen at openjdk.org  Tue Oct  7 17:20:31 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 17:20:31 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v3]
In-Reply-To: <Db1uIscnLCsYsdoEHp8ya19Z5narnOm5B_1I1bQPjE4=.f90cd251-31f4-47b7-83e9-a5bcc7f60c1a@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <dEUIaXmSftNpVQ-tqfFsAXetwlMbvEBWqbMp9vdTTPY=.da1e4904-f814-434d-b2e9-25aa1ded47d5@github.com>
 <Db1uIscnLCsYsdoEHp8ya19Z5narnOm5B_1I1bQPjE4=.f90cd251-31f4-47b7-83e9-a5bcc7f60c1a@github.com>
Message-ID: <B8auefwj-6pM4DD8jTfwrAAcz-lJY4OtDNIvJjHf95o=.f7a8a892-75a8-415e-8941-ced3bc95b979@github.com>

On Fri, 12 Sep 2025 17:47:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another tweak to make GHA gtest happy
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 235:
> 
>> 233:     // is_collector_free range.
>> 234:     region->restore_top_before_promote();
>> 235:     size_t region_to_be_used_in_old = region->used();
> 
> is region_to_be_used_in_old dead here?

It's not dead, but is only relevant within assertion.  Enclosing this code in #ifdef ASSERT

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2411330326

From kdnilsen at openjdk.org  Tue Oct  7 17:52:06 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 17:52:06 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v18]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <8ncMZBszoi0KvaMfQkkd_Bjv8G_UOWUwsg3BgIqlQqo=.f442633f-b304-45cb-8759-fb153744d57a@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:

 - finish excising shenandoahGenerationSizer
 - Remove ShenandoahGenerationSizer
 - remove stale comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/bd8e7f76..3ed66563

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

  Stats: 247 lines in 7 files changed: 1 ins; 242 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

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

From kdnilsen at openjdk.org  Tue Oct  7 17:52:09 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 17:52:09 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v12]
In-Reply-To: <nSBP3szWwdm3T_aArPlKNtT1gnGZ0XOBBTiVYQGDxX4=.3b89009d-bc68-435d-b690-fab6711b3866@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <zykF_uZbCnQ24lXQ7WDVnnbofQqtZbm3THblcpqnUnc=.c22227ea-3a1b-4507-b4f1-b48368c80fa3@github.com>
 <nSBP3szWwdm3T_aArPlKNtT1gnGZ0XOBBTiVYQGDxX4=.3b89009d-bc68-435d-b690-fab6711b3866@github.com>
Message-ID: <_RIw2rbRBf1AE9YAj1gexdcOj3CGmE-YqRq-XuWRozM=.41a68123-241f-4c63-9409-c08c8fcb8f24@github.com>

On Thu, 2 Oct 2025 23:35:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - small refactoring
>>  - OO refinements to used_regions_size()
>>  - fix broken assert from previous commit
>>  - OO refinements to free_unaffiliated_regions()
>>  - OO refinements to max_capacity()
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.hpp line 1:
> 
>> 1: /*
> 
> Is there any point in keeping this file now? Not sure what this class is doing now.

Thanks. Removing ShenandoahGenerationSizer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2411440425

From kdnilsen at openjdk.org  Tue Oct  7 18:01:21 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 18:01:21 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v19]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <RsLfTgMh5Z2EOGgPzRWvxKakigPvWjI60co8YZWkRUs=.b5b8058f-872a-4471-8499-19e9fb049a16@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/3ed66563..26a516ca

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

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

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

From ayang at openjdk.org  Tue Oct  7 18:25:47 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 18:25:47 GMT
Subject: RFR: 8369097: Parallel: Support allocation in from space when heap
 is too full [v2]
In-Reply-To: <uEZ5wcprvd6EY5dh9ZI52Br4ybO9L3Z5CkldaEuh2wE=.b9e07a4d-c62e-473d-b502-d831cb2a5b7a@github.com>
References: <uEZ5wcprvd6EY5dh9ZI52Br4ybO9L3Z5CkldaEuh2wE=.b9e07a4d-c62e-473d-b502-d831cb2a5b7a@github.com>
Message-ID: <tEPyKb2hRrAVZqICMLhKWB1Uu8uw92ahSXCpAe2pDmI=.3f51ab7b-e6d2-4d9b-a826-725a386386ea@github.com>

> Support allocation in from-space of young-gen in extreme cases (heap is almost full), so that gc-log shows used-heap is almost at max-heap when OOM is thrown.
> 
> Test: tier1-5

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

 - Merge branch 'master' into pgc-allocate-in-from-space
 - pgc-allocate-in-from-space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27620/files
  - new: https://git.openjdk.org/jdk/pull/27620/files/7c1efc07..403e34fc

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

  Stats: 6422 lines in 168 files changed: 5007 ins; 878 del; 537 mod
  Patch: https://git.openjdk.org/jdk/pull/27620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27620/head:pull/27620

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